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PREFACE 


The  purpose  of  this  Technical  Note  (TN)  for  the  AFGWC.  Real-Time  Nephanalysis 
(RTNEPH)  is  to  replace  AFGWC  TM  78-002,  the  AFGWC  Automated  Cloud  Analysis 
Model.  This  new  TN  will  provide  updated  information  to  reflect  the 
implementation  of  the  RTNEPH,  replacing  the  previous  3DNEPH  model,  in  August 
1983. 

The  earlier  Technical  Memorandum,  AFGWC  TM  78-002,  The  AFGWC  Automated  Cloud 
Analysis  Model,  by  then  Major  Falko  Fye  provided  an  excellent  reference  on 
cloud  analysis  techniques  at  AFGWC.  This  updated  TN  preserves  as  much  as 
possible,  the  structure  and  content  of  that  reference. 

The  authors  are  indebted  to  several  people  who  contributed  to  the  completion 
of  this  project: 

Major  Tim  Crum,  AFGWC/SDD,  for  his  many  reviews,  advice,  and  energy 
for  this  project. 

1st  Lt  Tom  Hamill,  AFGWC/SDDC,  for  his  assistance  in  preparing  the 
figures  and  reviewing  the  text. 

-  The  many  people  who  reviewed  this  TN: 

Mr  Arthur  Gulliver,  AFGWC/DO 
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SECTION  1.  INTRODUCTION 


The  RTNEPH  (Real  Time  NEFHanalysia)  model  replaced  the  3DNEPH  (3-Dimensional 
NEPHanalysia)  aa  the  Air  Force  Global  Weather  Central' a  (AFGWC)  cloud  analysis 
model  in  August,  1983.  Just  as  its  predecessor  3DNEPH  (Fye,  1978)  did,  the 
RTNEPH  continues  to  blend  high  resolution  satellite  data  and  conventional  data 
to  perform  an  automated  cloud  analyaia  at  25  nm  horizontal  resolution. 

RTNEPH  la  similar  to  the  3DNEPH  in  terms  of  basic  functions  and  algorithms. 
However,  RTNEPH  is  written  in  ANSI1  standard  FORTRAN  77  vice  FORTRAN  V  and 
enjoys  much  better  overall  program  documentation  than  3DNEFH,  Coupled  with 
structured  software  design  techniques,  RTNEPH  is  easier  to  maintain  and  to 
improve  with  new  algorithms. 

The  RTNEPH  contains  two  major  differences  from  3DNEPH  -  the  database 
definition  of  the  vertical  structure  and  the  addition  of  diagnostic 
Information.  RTNEPH  employs  four  floating  vertical  layers  vice  the  15  fixed 
layers  in  3DNEPH.  This  allows  a  greater  vertical  resolution  aa  cloud  bases 
and  tops  are  sharply  defined,  removing  constraints  on  applications  sensitive 
to  cloud  layer  definition.  The  addition  of  diagnostic  information  allows 
better  quality  control  techniques  and  more  detail  for  users  of  the  database. 

The  primary  use  of  RTNEPH  la  to  initialise  AFGWC  cloud  forecast  models.  AFGWC 
also  sends  the  data  to  USAFETAC/OL-A  where  they  are  stored  for  climatological 
purposes.  This  also  makes  RTNEPH  useful  for  cloud  climatology  studies;  recent 
examples  are  Hughes  and  Henderson-Sellers  (1985),  Curry  and  Herman  (1985),  and 
Henderson-Sellers  (1986).  Combined  with  the  3DNEPH,  RTNEPH  provides  a 
long-term  cloud  climatology  database,  especially  useful  with  the  recent 
Interest  in  cloud  climatology  in  the  world  community  (Shiffer  and  Rossow, 
1983). 

We'll  discuss  the  features  of  RTNEPH  important  for  users  to  know.  These 
include  the  grid  system;  database  contents;  the  satellite,  conventional, 
merge,  and  bogua  processors;  quality  control;  and  applications.  In  addition, 
we'll  discuss  RTNEPH 's  planned  future. 


SECTION  2,  GRID  SYSTEM 


2.1  Resolution  Considerations 

The  RTNEPH  grid  is  a  25  nm  (eighth  mesh)  polar  stereographic  grid  with  up  to 
four  cloud  layers  at  each  grid  point.  This  grid  was  determined  by  a  number  of 
considerations  described  below. 

2.1.1  Input  Data 

The  input  data  for  RTNEPH  have  characteristics  dictating  a  compromise  between 
fine  and  coarse  resolution.  The  satellite  data  used  by  RTNEPH  are  taken  from 
the  AFGWC  Satellite  Global  Data  Base  (SCDB).  The  SGDB  uses  unprocessed 
meteorological  satellite  data,  typically  at  1.5  nm  resolution,  and  processes 
them  to  give  smoothed  grayshade  values  on  an  approximately  3  nm  resolution 
grid.  To  get  a  representative  sample  of  cloud  layers,  a  set  of  points  (RTNEPH 
currently  uses  an  8  x  8  array  of  SGDB  values)  must  be  combined.  If  too  few 
points  are  combined,  the  analysis  loses  the  ability  to  determine  cloud  layer 
structure.  If  too  many  points  are  combined,  however,  the  analysis  loses  the 
fine  detail  provided  by  the  satellite  data.  Conventional  observations 
(surface  reports,  RAOBS,  PIREPs,  etc.)  are  also  used  as  input  to  RTNEPH. 

These  observations  typically  describe  an  area  with  a  radius  of  20  to  50  nm. 

If  the  resolution  of  the  grid  is  too  coarse,  many  conventional  observations 
may  occur  within  a  grid  box  causing  some  to  be  discarded  or  merged.  However, 
too  fine  a  grid  would  let  the  conventional  data  distort  the  analysis  provided 
by  the  satellite  data. 

2.1.2  Hardware  Restrictions 

The  RTNEPH  model  is  run  many  times  per  day  and  must  produce  timely  analyses. 

In  general,  as  grid  spacing  decreases,  computer  storage  and  processing  time 
increase.  In  order  to  meat  production  timelines,  the  RTNEPH  couldn't  have  a 
grid  size  of  leas  than  25  nm  on  the  then  present  AFGWC  computer  system. 

2.1.3  The  3DNEPH  Model 

The  predecessor  to  the  RTNEPH  model,  the  3DNEPH,  faced  many  of  the  same 
requirements  as  RTNEPH.  Its  designers  chose  the  eighth-mesh  (25  nm) 
resolution  to  satisfy  their  requirements  (Fye,  1978).  Staying  with  the  same 
horizontal  resolution  and  grid  projection  made  the  conversion  to  RTNEPH  much 
simpler. 

2.2  Horizontal  Grid 

The  RTNEPH  grid  is  overlayed  on  a  polar  stereographic  projection  true  at  60° 
latitude.  There  are  two  grids,  one  for  each  hemisphere.  Each  grid  is  a 
subset  of  the  AFGWC  Whole-mesh  Reference  Grid,  but  has  a  resolution  of 
approximately  25  nm  rather  than  200  nm,  and  is  therefore  called  an  eighth-mesh 
grid.  Each  grid  is  a  512  x  512  matrix  of  points,  with  the  poles  located  at 
grid  point  (257,257).  Each  grid  has  a  total  of  262,144  points  (Hoke  et.  al., 
1981). 


Only  a  small  number  of  points  in  the  eighth-mesh  grid  need  be  processed  at  any 
one  time.  Therefore,  the  grid  is  subdivided  into  a  Bet  of  64  RTNEPH  boxes, 
arranged  in  an  8  x  8  matrix,  and  numbered  1  to  64  (Figures  2.1  and  2.2).  Each 
box  contains  a  64  x  64  set  of  eighth-mesh  points.  If  a  point  is  off  the  map 
projection  (beyond  the  equator),  it  is  not  processed.  The  four  corner  boxes, 
1,  8,  57,  and  64,  are  all  completely  off  the  map  projection  and  are  not 
included  in  the  RTNEPH  database. 

2.3  Vertical  Grid 

The  data  in  RTNEPH  are  arranged  vertically  in  up  to  four  cloud  layers  at  each 
point.  Each  layer  has  information  on  cloud  amount,  type,  base  and  height. 

The  layers  are  sorted  by  cloud  base,  with  the  highest  base  in  layer  1.  The 
layers  can  overlap,  and  the  top  and  bottom  boundaries  are  not  fixed.  This  is 
the  primary  database  difference  between  the  3DNEPH  and  RTNEPH .  3DNEPH  used  a 
fixed  15  layer  vertical  stack.  However,  there  were  rarely  more  than  four 
layers  at  any  one  point,  so  RTNEPH  was  designed  to  restrict  the  number  of 
layers,  but  let  them  float  vertically  instead,  providing  finer  vertical 
resolution. 

The  layer  heights  can  range  from  the  surface  to  21900  m  mean  sea  level  (MSL). 
The  spacing  resolution  is  30  m  below  6000  m,  and  300  m  above  6000  m. 


Figure  2 1  Northern  Hemisphere  RTNEPH  grid  over  a  polar-stereographic 
projection,  Each  square  partition  is  an  RTNEPH  box  ( 1 600  nm  on  a  side), 

Corner  boxes  are  not  used, 


Figure  2  2  Southern  Hemisphere  RTNEPH  grid. 


SECTION  3.  SYSTEM  OVERVIEW 


In  this  section,  we'll  briefly  discuss  the  different  RTNEPH  modules,  the 
RTNEPH  and  supporting  databases,  and  the  RTNEPH  operating  environment. 

3.1  Basic  RTNEPH  Functions  aa  Processing  Modules 

One  of  the  basic  philosophies  of  the  RTNEPH  design  was  to  construct  processing 
modules  along  the  lines  of  the  major  functions.  This  modular  approach 
permitted  a  software  structure  easier  for  programmers  and  systems  analysts  to 
learn,  maintain,  and  Improve.  Additionally,  the  modular  approach  permitted 
processing  to  be  distributed  over  different  mainframe  computers,  thus 
permitting  an  expedient  processing  of  as  much  data  as  possible. 

There  are  six  basic  modules  within  the  RTNEPH  system.  The  three  primary 
modules  and  their  functions  are: 

a.  Satellite  Processor,  which  performs  a  cloud  analysis  based  on 
satellite  data  only  and  produces  an  intermediate  database. 

b.  Conventional  Processor,  which  builds  an  intermediate  analysis  based 
solely  on  conventional  data  (surface  observations,  rawinsonde  observations, 
and  aircraft  pilot  reports). 

c.  Merge  Processor,  which  merges  the  satellite  and  conventional  analyses 
into  the  actual  RTNEPH  database. 

These  three  modules  make  up  the  core  of  the  RTNEPH  system  as  shown  in  Figure 
3.1.  The  system  is  completed  by  adding  three  support  modules,  namely: 

a.  Bogus  Processor,  which  allows  manual  modification  to  correct 
deficiencies  in  the  automated  analysis. 

b.  Display  Processor,  which  allows  specific  parameters  to  be  displayed  in 
formats  useable  to  meteorologists. 

c.  Driver  Module,  which  schedules  the  execution  of  the  Satellite  and 
Merge  Processors  based  on  availability  of  data  and  computer  resources. 

These  six  processor  modules  come  together  as  a  system  as  shown  in  Figure  3.2. 

3.2  Support  and  Peripheral  Databases 

Figures  3.1  and  3.2  provide  a  road  map  for  the  software  modules  themselves. 
However,  equally  important  are  the  databases  which  provide  direct  data  inputs 
or  provide  data  supporting  the  analysis  of  conventional  or  satellite  data. 
Examples  of  these  databases  are: 

a.  Geography /Terrain  database,  which  includes  terrain  heights  as  well  as 
indicators  of  geography  type  (e.g.,  land,  water,  coast,  ice-covered  water)  for 
the  1/gth  meeh  grid. 
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Figure  3.1  Relationship  of  the  primary  RTNEPH  processors  and  analyses. 
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b.  Satellite  Global  Data  Base  (SGDB),  the  array  of  satellite  data 
represented  by  grayshades  for  3  nm  resolution  pixels. 

c.  Background  brightness  database,  which  contains  a  background  brightness 
for  the  visual  satellite  data  at  25  nm  resolution  to  be  compared  against  for 
determining  cloud-covered  pixels. 

d.  Surface  temperature  database,  which  contains  surface  temperatures  at 
l/8th  mesh  for  the  infrared  satellite  data  to  use  for  determining 
cloud-covered  pixels. 

e.  Upper  air  temperature  database,  used  to  calculate  the  tops  of  cloud 
layers  derived  from  infrared  satellite  data.  The  resolution  is  200  nm  or 
whole  mesh. 

f.  Conventional  reports  database,  containing  the  conventional  reports 
used  in  the  conventional  processor. 

g.  Tuning  databases,  sets  of  processing  parameters  used  in  the  individual, 
processors  and  easily  modified  by  meteorological  database  analysts  to  adjust 
or  improve  the  analysis, 

Just  as  we  need  to  understand  the  linkage  between  processors,  we  need  to 
understand  the  linkage  between  the  processors  and  these  databases  as  shown  in 
Figure  3.3, 

3.3  General  Contents  of  the  RTNEPH  Database 

A  detailed  description  of  the  contents  and  meaning  of  the  database  entries  is 
provided  in  Section  8.  However,  consistent  with  providing  a  general 
description  of  the  processing  structure,  we'll  provide  a  general  description 
of  the  database.  The  database  information  at  each  grid  point  can  be  divided 
Into  four  groups s 

a.  The  total  cloud  amount,  present  weather,  visibility,  and  valid  time  of 
the  data  at  the  grid  point. 

b.  Data  for  each  of  the  (up  to  four)  layers,  specifically  layer  cloud 
amount,  layer  cloud  type,  layer  base  and  layer  top. 

c.  Layer  source  information  which  defines,  for  each  of  the  layers, 
whether  the  layer  was  derived  from  satellite  data  or  conventional  data, 
whether  the  base  or  top  was  estimated,  etc. 

d.  Diagnostic  information,  primarily  for  quality  control  and  studies 
requiring  detailed  data  source  description,  which  includes  indices  for 
denoting  whether  infrared  data  were  used,  whether  visual,  data  were  used,  and 
so  on.  These  diagnostic  factors  will  be  fully  discussed  in  the  database 
section. 


mr****. 
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3.4  Operating  Modes 

RTNEPH  operates  in  one  of  three  modes  in  the  AFGWC  production  cycle:  sprint , 
non-sprint,  and  update  (synoptic).  Each  operation  mode  is  for  a  specific 
purpose. 

3.4.1  The  Sprint  Cycle 

The  sprint  cycle,  as  suggested  by  its  name,  is  designed  to  Incorporate  a 
quarter  orbit  of  satellite  data  as  quickly  as  possible  into  the  RTNEPH  and 
from  there,  into  a  cloud  forecast  model.  The  sprint  cycle  ia  triggered  by  the 
receipt  of  a  quarter  orbit  of  data  into  the  AFGWC  computer  systems.  The  data 
are  mapped  into  the  SGDB  and  then  the  RTNEPH  Satellite  and  Merge  Processors 
process  the  RTNEPH  boxes  containing  nev  satellite  data.  The  RTNEPH  output  is 
manually  quality  controlled  and  if  need  be,  changes  are  input  via  the  Bogus 
Processor.  The  sprint  cycle  is  outlined  in  Figure  3.4. 

3.4.2  The  Non-Sprint  Cycle 

The  non-sprint  cycle  is  similar  to  the  sprint  cycle  except  the  timeliness, 
manual  quality  control,  and  immediate  cloud  forecast  model  input  restrictions 
are  lifted.  It  too,  operates  on  a  quarter  orbit  by  quarter  orbit  basis. 

Though  the  non-sprint  isn't  as  time  critical  aa  a  sprint,  It  is  extremely 
important  for  the  complete  database.  The  non-sprint  cycle  is  outlined  in 
Figure  3.5. 

3.4.3  The  Update  (Synoptic)  Cycle 

The  purpose  of  the  update  cycle  is  to  incorporate  as  much  data  as  possible 
every  three  hours  before  making  a  "synoptic"  copy.  Unlike  the  sprint  and 
non-sprint  cycles,  the  update  cycle  operates  on  a  hemispheric  basis.  All 
remaining  unprocessed  quarter  orbits  from  the  last  update  cycle  are  processed 
in  the  Satellite  Processor.  Then  this  data  is  merged  with  the  most  recent 
conventional  data.  Finally,  a  snapshot  of  the  database  is  created  to  make  the 
synoptic  copy.  The  northern  update  is  built  approximately  two  hours  after 
data  time  (00Z  built  at  02Z)  and  the  southern  is  built  three  hours  after  data 
time,  The  update  cycle  is  outlined  in  Figure  3.6. 

3.4.4  Conventional  Data  Processing 

RTNEPH  processes  conventional  data  upon  receipt  of  regular  surface  data. 

These  updates  are  normally  once  an  hour.  Therefore,  the  RTNEPH  Conventional 
Processor  runs  about  once  an  hour  and  the  data  it  produces  is  available  for 
the  Merge  Processor. 
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Figure  3,4  Processing  flow  of  the  AFGWC  Sprint  Cycle.  The  Sprint 
Cycle  operates  on  a  quarter  orbit  basis. 
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Figure  3,5  Processing  flow  of  the  AFGWC  Non-Sprint  Cycle. 
The  Non-Sprint  Cycle  operates  on  a  quarter-orbit  basis. 


m 


JMVivivn t,  . 

•*^  *•*  “■»*  •‘•4.  •♦■t- 


Figure  3,6  Processing  flow  of  the  AFGWC  update  cycle,  The  Update  Cycle 

operates  on  a  hemispheric  basis. 


SECTION  4.  CONVENTIONAL  PROCESSOR 

The  RTNEPH  Conventional  Processor  remains  nearly  the  same  as  the  3DNEPH 
Conventional  Processor  with  the  following  exceptions: 

a.  It  conforms  to  the  RTNEPH  vertical  layer  format  (4  floating  layers) 
rather  than  the  3DNEPH  format  (15  fixed  layers)  and 

b.  It  ia  written  in  FORTRAN  77  instead  of  FORTRAN  V. 

Since  the  overall  algorithm  and  flow  remains  nearly  the  same,  much  of  this 
section  is  taken  from  the  3DNEPH  Technical  Memorandum  (Fye,  1978). 

The  Conventional  Processor  takes  surface,  aircraft,  and  upper  air  reports  from 
the  AFGWC  database }  sorts,  screens,  and  combines  reports  to  produce  a  gridded 
eighth-mesh  database  of  cloud  and  weather  Information.  This  database,  known 
as  the  Best  Reports  File,  contains  only  gridpolnts  for  which  data  are 
available  and  is  in  RTNEPH  format  -  including  the  vertical  levels.  Figure  4.1 
shows  the  overall  flow  of  the  process.  Table  4.1  provides  an  idea  of  the 
quantity  of  data  processed.  The  Conventional  Processor  is  broken  down  into 
four  parts:  the  surface  data  processor,  the  upper  air  data  processor,  the 
aircraft  processor,  and  the  decision  tree  processor.  We'll  discuss  each 
processor  in  detail. 

4.1  Surface  Data  Processor 

The  surface  data  processor  determines  cloud  amounts  for  up  to  four  layers  from 
several  sources  of  validated  surface  reports. 

4.1.1  Data  Types  and  Time  Considerations 

Cloud  data  are  extracted  from  synoptic,  METAR,  and  Airways  coded  reports.  If 
more  than  one  type  of  report  is  available  at  a  given  time,  all  unique 
information  from  both  reports  ia  used  to  produce  a  composite  report. 
Conflicting  information  is  resolved  with  consideration  for  data  timeliness  and 
implicit  data  quality.  All  surface-baaed  observations  of  cloud  data  are 
ranked  above  upper  air  sounding  data.  All  hourly  and  special  surface  reports 
valid  since  three  hours  before  the  analysis  valid  time  are  considered.  Figure 

4.2  shows  the  typical  rate  of  data  flow  into  AFGWC. 

4.1.2  Present  Weather 

Present  weather  is  converted  to  a  weather  factor  (KWEA)  and  is  used  to 
determine  cloud  layers  and  types.  Table  4.2  shows  the  conversion  to  KWEA. 

The  most  significant  present  weather  element,  from  WMO  Code  4677,  is  included 
as  an  independent  parameter  in  the  RTNEPH  database.  If  fog  or  haze  is 
superseded  by  a  reported  higher  value,  a  flag  is  set  to  indicate  this.  This 
information  is  used  later  by  the  Merge  Processor.  Missing  weather  is  reported 
as  127. 
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Figure  41  Functional  flow  chart  of  the  Conventional  Processor 

(fromFye,  1978), 
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TOTAL  BEST  REPORTS 

bill 

5301 

1366 

5114 

5663 

6068 

5490 

5700 

625 

658 

732 

m 

UNCOHHlNKD  REPORTS 

1  280? 

1219  1 

12004 

12175 

13781 

14990 

13951 

1  368  7 

1144 

1032 

1501 

1410 

Table  4  1  Typical  numbers  of  conventional  reports  received  by  the  RTNEPH 
by  RTNEPH  box,  time,  and  hemisphere.  These  reports  are  integrated  to 
produce  the  "Best  Reports"  (from  Fye,  1978). 


PERCENT  OF  TOTAL 
REPORTS  RECEIVED 


Figure  4.2  Graphic  representation  of  conventional  data  flow  into  AF6WC, 
Selected  areas  are  shown  as  typical  examples.  World  Meteorological 
Organization  (WMO)  Blocks  represent  particular  areas  of 1  he  world. 

(from  Fye,  1978). 
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Table  4.2 


CONVERSION  OF  PRESENT  WEATHER  TO  WEATHER  FACTOR  (from  Fye,  1978) 


Type  of  Weather 

WW  (WMO  Code  4tdll 

KWEA 

0-9 

0 

Mist 

10 

1 

11-14 

0 

Precipitation  in  sight 

15 

1 

Precipitation  in  sight 

16 

2 

Thunder 

17 

2 

Squalls 

18 

2 

Funnel  clouds 

19 

3 

Drizzle,  past  hour 

20 

1 

Rain/Snow,  past  hour 

21-22 

1 

Rain/Snow,  past  hour 

23 

2 

Freezing  drizzle/rain,  past  hour 

24 

1 

Rain/Snow  showers,  past  hour 

25-26 

2 

Showers  (hail/rain/snow) ,  past  hour 

27 

2 

Ice  fog,  past  hour 

28 

0 

Thunderstorm,  past  hour 

29 

2 

— 

30-49 

0 

Drizzle 

50-59 

1 

Rain 

60-69 

2 

Snow 

70-79 

2 

Showers 

80-89 

2 

Thundershowers 

90-99 

3 

Missing  weather 

127  (RTNEPH 

4.1.3  Visibility 

The  horizontal  visibility  at  the  surface  is  converted  to  code  values 
corresponding  to  WMO  Code  4377  (Table  4.3).  When  the  visibility  is  missing  or 
not  reported,  the  value  in  the  database  is  set  to  255. 


Table  4.3 


VISIBILITY  CONVERSIONS 


;  Visibility  (Km) 

Code  Value 

(Range) 

0.1 

00 

(00) 

0. 1-5.0 

vis  X  10.1 

(01-50) 

6.0-30.0 

vis  +  50 

(56-80) 

30.0-70.0 

(vis/5)  +  74 

(80-88) 

70.0  + 

89 

(89) 

4.1.4  Layered  Cloud  Data 


When  cloud  amounts  are  specified  In  reports,  the  data  are  stored  directly. 
Scattered,  broken,  and  overcast  cloud  amounts  are  assigned  25,  75,  and  100 
percent  coverage,  respectively.  Reported  cloud  bases  are  converted  to  meters 
MSL  and  coded  according  to  Table  4.4. 

Table  4.4 


Code  Values 
0-200 


201-253 


254 

255 


CLOUD  HEIGHTS 

CflfinltiOM 

30  meter  increments  for 
0-6000  meters  MSL. 

MSL  HOT  -  Code  x  30 

300  meter  increments  for 
6001-21900  meters  M8L. 

MSL  HGT  -  (Code  -  200)  X  300 
+  6000. 

Greater  than  21900  meters  MSL. 
Height  not  available. 


Reported  cloud  types  are  converted  to  code  values  as  shown  in  Table  4.5.  If 
all  four  RTNEPH  layers  contain  clouds  and  a  surface-based  layer  of  fog  is 
located  beneath  the  lowest  layer,  the  KTHEFH  will  indicate  fog  by  adding  10  to 
the  cloud  type  of  the  lowest  layer  (l.e.,  if  stratus  was  the  lowest  layer, 
then  its  code  value  would  be  12  instead  of  2). 


Table  4.5 


CLOUD  TYPES 


Code  Value 


Cloud  Type 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
25 


Clear 

Cumulonimbus  (CB) 
Stratus  (ST) 
Stratocumulus  (SC) 
Cumulus  (CU) 
Altostratus  (AS) 
Nimbostratus  (HS) 
Altocumulus  (AC) 
Cirrostratus  (CS) 
Cirrocumulus  (CC) 
Cirrus  (Cl) 
Unknown 


A.l.S  Special  Considerations  for  Synoptic  Data 

Synoptic  data  contain  limited  cloud  information  about  layered  amounts.  The 
only  layered  data  are  the  amount  of  all  low  or  middle  clouds  and  the  base  of 
the  lowest  clouds  visible.  If  more  than  one  low  or  middle  cloud  layer  is 
observed,  the  synoptic  reports  do  not  contain  sufficient  information  to  define 
each  layer.  The  following  procedures  are  used  with  synoptic  reports: 

4. 1.5.1  Layered  Amounts 

Cloud  height  categories  are  determined  from  synoptic  data.  These  categories 
are  low  (surface  to  6500  ft  above  the  ground),  middle  (6500  to  22000  ft  MSL) , 
and  high  (above  22000  ft  MSL).  Cloud  amount  probabilities  are  assigned  to 
height  categories  based  on  the  lowest  cloud  reported  and  the  types  of  clouds. 

a.  If  a  cloud  type  is  not  observed,  zero  percent  probability  is  assigned 
to  the  corresponding  height  category. 

b.  When  a  valid  cloud  type  is  given,  100  percent  probability  is  assigned. 

c.  For  a  missing  cloud  type,  50  percent  probability  is  assigned. 

Actual  layered  cloud  amounts  are  then  computed,  based  on  the  total  sky  cover, 
if  available,  using  the  assumption  that  clouds  are  randomly  distributed.  If 
sky  cover  and  cloud  amounts  are  missing,  the  synoptic  report  is  discarded. 

4. 1.5. 2  Cloud  Bases 

If  the  base  of  the  cloud  layer  is  reported,  then  the  surface  data  processor 
will  use  it.  Otherwise,  the  base  of  clouds  in  the  three  height  categories  may 
be  calculated  as  follows: 

a.  Base  of  low  clouds  (H^)  in  meters  AGLs 

Hl  -  670.7  -  (91.46  X  KWEA)  (1) 

b.  Base  of  middle  clouds  is  set  at  3565.986  meters  AGL. 

c.  Base  of  high  clouds  (Hr)  in  meters  AGL: 

Hh  -  10670.732  -  44.03794  (Latitude)  (2) 

After  the  conversion  to  meters,  the  terrain  elevation  is  added  for  MSL 
heights  and  bases  are  coded  according  to  Table  4.4. 

4.1.6  Surface  Obscurations 

Clouds  are  assigned  with  the  cloud  base  at  terrain  level  if  a  report  indicates 
fog  and/or  visibility  less  than  1  mile  (1600  meters).  The  cloud  amount  is 
determined  from  the  type  of  fog  and  layer  depth  is  determined  from  the 
horizontal  visibility.  Higher  clouds  are  allowed  if  no  obscuration  (-X  or  X) 
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Is  reported.  For  a  total  obscuration,  100  percent  cloud  coverage  is  assumed 
with  the  base  equal  to  the  vertical  visibility.  If  the  vertical  visibility  is 
missing,  the  cloud  base  is  computed  as  a  function  of  the  present  weather. 

4.1.7  Thin  Clouds 

Thin  clouds  may  be  reported  in  the  Airways  surface  report  code.  Such 
information  is  stored  in  the  Best  Reports  File  and  la  useful  in  computing 
cloud  thickness. 

4.1.8  Total  Sky  Cover 

When  specified  in  a  report,  the  total  sky  cover  is  stored  and  retained  through 
all  subsequent  processing.  When  unavailable,  the  maximum  cloud  layer  amount 
is  used  to  arrive  at  a  total  cloud  amount. 

4.1.9  Cloud  Tops 

The  surface  data  processor  makes  no  assessment  of  cloud  tops.  The  code  value 
for  height  not  available  <255 >  is  stored  in  the  Best  Reports  File. 

4,2  Upper  Air  Data  Processor 

An  AF6WC  database  provides  upper  air  data  containing  reports  from  rawinsondea, 
dropsondas,  rocketsondes ,  and  satellite  soundings.  The  ravlneonds  reports  are 
screened  and  used  to  locate  layered  clouds  by  performing  a  moisture  analysis 
of  the  available  data.  The  stepwise  procedure  for  cloud  amount  determination 
is  described  in  the  following  paragraphs. 

4.2.1  Vertical  Structure 


The  analysis  of  the  rawinaonde  is  based  on  the  approach  used  in  the  3DNEPH 
model.  A  vertical  grid  consisting  of  15  layers  of  varying  thickneas  from  the 
surface  to  55,000  feet  is  used  to  determine  the  cloud  layer  information.  The 
15  "RTNEPH"  layers  are  divided  into  6  terrain-following  layers  that  are 
specified  with  respect  to  local  terrain  height  and  9  layers  that  are  specified 
with  respect  to  mean  sea  level  (MSL).  The  structure  and  details  of  the  layers 
are  shown  in  Table  4.6. 


Table  4.6 

RTNEPH  LAYERS  FOR  RA0B  CLOUD  LAYER  DETERMINATION 


Layer 

Height 

Pressure 

Thickness 

ft  (m) 

Level  (mb) 

ft  (m) 

Surface 

1 

150  (46)  A6L 

150  (46) 

2 

300  (91)  AGL 

150  (46) 

3 

600  (183)  AGL 
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300  (92) 

4 

400  (122) 

1000  (305)  AGL 

5 

1000  (305) 

2000  (610)  AGL 

6 

1500  (457) 

3500  (1067)  AGL/MSL 

7 

1500  (457) 

5000  (1524)  MSL 

850 

8 

1500  (4570) 

6500  (1981)  MSL 

800 

9 

3500  (1067) 

10000  (3048)  MSL 

700 

10 

4000  (1219) 

14000  (4267)  MSL 

600 

11 

4000  (1219) 

18000  (5486)  MSL 

500 

12 

4000  (1219) 

22000  (6706)  MSL 

430 

13 

4000  (1219) 

26000  (7925)  MSL 

360 

14 

9000  (2743) 

35000  (10668)  MSL 

240 

15 

20000  (6096) 

55000  (16764)  MSL 

100 

4.2.2  Missing  Data 

Where  not  specified  in  the  database ,  heights  are  computed  using  the 
hypsometric  equation.  Temperature-dew  point  spread  values  are  computed  when 
required  according  to: 

T  -  Td  -  0.285  (T  -  273)  +  20.6  (3) 

where  T  is  the  temperature  in  Kelvin  degrees  and  Tj  is  the  dew  point  in 
Kelvin  degrees. 

4.2.3  Midpoint  Values 

Pressure,  temperature  and  temperature-dew  point  spread  are  computed  for  the 
midpoint  of  a  RTNEPH  layer  by  interpolating  between  adjacent  reported  levels. 
Midpoint  values  of  MSL  are  computed  directly  and  midpoint  values  for  the 
terrain-following  layers  are  computed  by  subtracting  the  station  elevation 
from  the  report  height. 

4.2.4  Condensation  Pressure  Spread  (CPS) 

The  CPS,  defined  as  the  dry-adiabatic  pressure  change  required  for  a  parcel  to 
attain  saturation,  is  computed  from  the  pressure,  temperature  and 
temperature-dew  point  spread  for  each  layer  and  is  used  to  relate  atmospheric 
moisture  content  to  cloud  amount.  The  uncorrected  CPS,  Cu,  is  given  as  an 
approximate  by  Edson  (1965): 
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(4) 


C„  -  (T  -  TahI-4.9  -  0.93<  P1  )-  9.0(  P1  )2  ] 

t mr  vm~ 

where  Cu,  T,  end  were  defined  previously,  end  P  Is  the  pressure  et  the 
midpoint  of  e  layer. 

4.2.5  Cloud  Amount  From  CPS 

Finally,  the  cloud  emount  is  estimeted  from  e  CPS-cloud  amount  conversion 
table  derived  by  Bdson  <1965).  Use  of  the  tebles  requires  calculation  of  an 
index,  1,  as  follows t 

I  -  0.5  KCU  +  1.5  (5) 

where  K  is  a  correction  factor  based  on  temperature  at  the  midpoint  of  a 
layer.  Figure  4.3  shows  the  CPS-cloud  emount  relation  described  by  Bdson. 
Separate  curves  are  provided  for  the  850,  700,  500,  and  300  mb  levela. 

4.3  Aircraft  Data  Processor 

The  aircraft  data  processor  computes  total  and  layered  cloud  amounts  from 
various  types  of  validated  aircraft  reports  encoded  in  the  RICCO,  ICAO,  and 
USAF  aircraft  report  formate.  Three  types  of  coded  information  are  used! 
flight  veather  (Table  4.7),  flight  condition  (Table  4.8),  and  explicit  cloud 
layer  data.  Total  and  layered  cloud  amount  decisions  are  described  below. 

4.3.1  Total  Cloud  Amount 

The  following  decisions  determine  the  total  cloud  covert 

a.  If  the  flight  condition  is  clear  (coded  1),  the  total  cloud  amount  is 
set  to  aero  percent, 

b.  If  the  flight  condition  is  coded  5,  9,  or  18,  the  total  cloud  amount 
is  set  to  100  percent. 

c.  If  flight  veather  is  coded  5,  6,  or  7,  the  total  cloud  amount  is  set 
to  100  percent, 

d.  If  the  cloud  amount  in  a  reported  layer  is  overcast,  the  total  cloud 
amount  is  set  to  100  percent. 

e.  If  none  of  the  above  are  available,  the  total  cloud  is  set  to  missing. 
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Figure  43  Relationship  between  Condensation  Pressure  Spread 
(CPS)  and  cloud  amount  for  various  levels  in  the  atmosphere 

(from  Fye,  1978), 


25 


Table  4.7 


Code  Figure 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 


AIRCRAFT  FLIGHT  WEATHER 
Weather 

Clear  (no  clouda  at  flight  level) 

Partly  cloudy  (acattered  or  broken) 
Continuoua  layer(a)  or  eloud(a) 

Sandstorm,  duet  storm,  or  atom  of  drifting 
anow 

Fog,  thick  duat,  or  haie 

Drizzle 

Rain 

8now  or  rain  and  anow  nixed 
Shower(a) 

Thunderatorm(a) 

Lightning 
Scattered  clouda 
Broken  clouda 


4.3.2  Layered  Cloud  Amounta 

Layered  cloud  data  are  rather  limited  in  aircraft  reporta  and  when  available, 
usually  describe  conditions  only  in  the  vicinity  of  the  aircraft.  The 
following  decialona  can  be  made  from  the  flight  condition  codot 

a.  If  coded  11  or  12,  there  are  no  clouda  above  the  flight  level. 

b.  If  coded  15  or  16,  thara  are  no  clouda  below  the  flight  level. 

c.  If  clear  at  flight  level,  cloud  layers  are  determined  directly.  If 

bases  or  tops  are  available,  but  the  amount  ia  missing,  a  cloud  amount  of  60 
percent  la  assumed.  If  inconsistencies  develop  because  two  or  more  coded 
report  typea  are  contained  in  a  single  aircraft  report,  apecific  layered 
Information  is  given  hlgheat  priority  followed  by  flight  condition  reports  and 
flight  weather  reporta. 


Table  4.B 

AIRCRAFT  FLIGHT  CONDITION 
Code  Figure  Flight  Condition 

0  Total  amount  of  cloud  laea  than  1/8. 

1  Total  cloud  amount  at  least  1/8,  with  either  1/8-4/8  above  or 

1/8-4/8  below,  or  a  combination  thereof. 

2  Cloud  amount  more  than  4/8  above  and  0-4/8  below. 

3  Cloud  amount  0-4/8  above  and  more  than  4/8  below. 

4  Cloud  amount  more  than  4/8  above  and  more  than  4/8  below. 

5  Chaotic  aky  -  many  undefined  layers. 


6  In  and  out  of  clouds,  on  instruments  25X  of  time. 

7  In  and  out  of  clouds,  on  instruments  50X  of  time. 

8  In  and  out  of  clouds,  on  instruments  75X  of  time. 

9  In  clouds  all  of  the  time,  continuous  instrument  flight. 

10  Clear  (no  clouds  at  any  level). 

11  Above  clouds  (tops  less  than  10000  ft). 

12  Above  clouds  (tops  10000-18000  ft). 

13  Above  clouds  (tops  above  18000  ft). 

14  Belov  clouds  (bases  less  than  10000  ft). 

15  Bslov  clouds  (bases  10000-18000  ft). 

16  Belov  clouds  (bases  above  18000  ft). 

17  Between  broken  or  overcast  layers. 

18  In  clouds . 

19  In  and  out  of  clouds. 

4.4  Decision  Tree  Processor 

The  decision  tree  processor  integrates  surface,  upper  air,  and  aircraft  data 
such  that  only  one  report,  containing  the  best  information  from  possible 
multiple  reporte,  is  given  per  gridpoint.  When  two  or  more  conventional 
reports  are  within  a  15  nm  radius  of  an  eighth-mesh  gridpoint,  a  single  report 
must  be  selected  or  the  reports  must  be  integrated  to  produce  a  single  best 
report.  A  final  module  of  this  processor  sorts  the  integrated  reports  to 
produce  an  ordered  database  in  RTIfEPH  eighth-mesh  format, 

4.4.1  Best  Surface  Report  Selection 

A  single  report  may  be  selected  using  the  following  decision  criteria t 

a.  The  report  with  the  largest  total  cloud  amount  is  used. 

b.  If  the  reports  have  identical  total  cloud  amounts,  the  report  vith  the 
loveat  cloud  layer  is  used. 

c.  If  total  cloud  cover  for  the  lowest  cloud  layer  are  the  same,  the 
report  received  last  by  RTHEPH  ie  used. 

4.4.2  Merging  Surface  Reports 

The  moat  recent  report  is  used  and  if  an  overcast  layer  is  reported,  any 
available  reports  up  to  3  hours  old  are  searched  for  additional  cloud 
Information  above  the  overcast  layer.  Multiple  overcast  layers  are  allowed. 

4.4.3  Integration  of  All  Conventional  Data 

The  following  decisiona  are  made  when  two  or  more  conventional  reports 
Influence  a  single  gridpoint, 

a.  The  process  begins  with  the  surface  report  sb  the  initial  report. 
Surface  data  are  ranked  highest  below  10000  ft  MSL. 


b.  Data  from  aircraft  report*  are  integrated  into  layer*  above  10000  ft. 

c.  Upper  air  report*  are  etored  only  for  thoae  eighth-mash  gridpoints  at 
which  there  ere  no  surface  or  aircraft  reporta. 

4.4.4  Beat  Reports  File 

The  final  function  of  the  daciaion  tree  procaaaor  ia  the  sorting  and  storage 
of  the  reports  in  the  Beat  Reports  File.  This  file  ia  updated  hourly  and  is 
used  by  tha  Marge  Processor  where  it  is  merged  with  satellite  data  and  the 
current  RTNEPH  analysis. 


SECTION  5.  SATELLITE  PROCESSOR 

The  Satellite  Processor,  by  analyzing  satellite  data,  provides  the  predominant 
data  source  for  the  RTNEPH.  Unlike  conventional  data,  satellite  data  isn't 
conatrained  by  uneven  distribution,  sparclty  over  remote  land  areas,  or  by 
virtual  absence  over  ocean  areaa.  With  two  polar-orbiting  satellites,  for 
exsaple,  virtually  every  data  point  is  assured  of  being  updated  four  times  a 
day |  grid  points  near  the  poles  get  updates  virtually  continuously  because  of 
the  overlap  of  the  orbit  swaths  (Figure  5.1).  The  RTNEPH  processing  software 
and  algorithms  can  handle  data  from  up  to  four  satellites  as  long  as  the  data 
have  been  mapped  Into  the  Satellite  Global  Data  Base  (SGDB).  However,  since 
its  implementation  in  1983,  the  RTNEPH  has  been  primarily  limited  to 
processing  data  from  two  polar-orbiting  satellites  due  mostly  to  computer 
hardware  and  satellite  ingest  restrictions. 

5.1  General  Processing 

The  basic  principles  for  determining  cloud  cover  characteristics  from 
satellite  data  are  fairly  straightforward,  but  require  an  extensive  amount  of 
supporting  data.  This,  however,  is  a  reasonable  tradeoff  considering  the 
amount  of  Information  to  be  derived  from  the  satellite  data. 

5.1.1  Underlying  Principles 

Currently  processed  meteorological  satellite  data  consists  of  visual  and 
infrared  data.  In  general,  darker,  or  less  bright,  visual  data  are  associated 
with  cloud-free  land  or  ocean  areas.  Likewise,  lighter  or  brighter  visual 
data  are  associated  with  clouds  but,  unfortunately,  may  also  be  associated 
with  snow,  sunglint  areas  and  highly  reflective  terrain  such  as  deserts,  salt 
flats,  or  dry  lake  beds. 

Infrared  data,  on  the  other  hand,  represents  temperature  in  terms  of 
brightness.  Figure  5.2  shows  some  general  comparisons  of  temperatures  and 
typos  of  terrain  or  clouds.  For  purpoaea  of  the  RTNEPH,  brighter  infrared 
measurements  indicate  colder  temperatures  (inverted  from  the  normal  senaor 
standard  of  colder  temperatureo  represented  by  lover  brightness  values,  which 
Indicate  lower  radiated  energy).  Although  both  visual  and  infrared  data 
provide  brightness  values  indicating  amounts  of  reflected  (visual)  or  radiated 
(infrared)  energy,  the  determination  of  cloud  cover  requires  a  comparison  of 
the  sensed  values  with  expected  background  values.  For  visual  data,  the 
background  ia  a  variation  of  surface  albedo;  for  infrared  data,  the  background 
is  the  surface  temperature.  For  cloud  cover  determination  the  basic  rule  then 
becomes!  for  visual  data,  if  the  sensed  values  are  brighter  than  the  expected 
background  brightness,  then  clouds  are  present;  for  infrared  data,  if  the 
sensed  values  are  colder  than  the  expected  surface  temperature  by  a  given 
amount,  then  clouds  are  present. 

5.1.2  Inputs  and  Outputs 

The  variety  of  input  data  and  the  resultant  outputs  are  shown  in  Figure  5.3. 
Specifically.,  the  input  data  are: 
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FIGURE  5,2  Relationship  between  infrared-determined  temperatures 
and  cloud  and  surface  temperature,  The  ovals  give  an  approximate 
range  of  temperature  for  each  parameter, 
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a.  The  Satellite  Global  Data  Base,  containing  visual  and  infrared  data  on 
an  approximately  3  nm  by  3  nm  basis;  the  data  are  represented  by  grayshades. 

b.  Tuning  parameters,  such  as  grayshade-to-temperature  conversion  tables, 
which  will  be  discussed  in  more  detail  in  the  visual  and  infrared  processing 
descriptions . 

c.  Terrain  heights  and  geography  types.  Terrain  heights  are  used  to 
estimate  cloud  layer  tops  and  bases.  Geography  types  (specifically  land, 
water,  coast  or  ice)  are  used  to  insert  variations  in  the  cloud  determination 
algorithms. 

d.  Background  brightness  fields  provide  the  background  against  which 
visual  data  will  be  compared  to  determine  cloud  cover  characteristics.  Note 
that  not  only  are  the  background  brightness  fields  an  input  to  the  processing, 
but  are  also  an  output  as  the  new  visual  satellite  data  are  used  to  update  the 
brightness  values.  We'll  discuss  this  automatic  updating  later. 

e.  Surface  temperatures  (see  Fye,  1978  for  a  description  of  the  surface 
temperature  model)  provide  the  background  against  which  infrared  data  will  be 
compared  to  determine  cloud  cover  characteristics. 

f.  Upper  air  temperatures  are  used  to  define  the  tops  of  infrared- 
determined  cloud  layers. 

The  two  sets  of  output  data  are  the  updated  background  brightness  data  and  the 
satellite  analysis.  The  satellite  analysis  is  an  analysis  based  solely  on  the 
interpretation  of  the  newly  processed  satellite  data.  The  specific  contents 
of  this  intermediate,  satellite  data-only  analysis  are; 

a.  Visual  data  total  cloud. 

b.  Visual  data  cloud  type. 

c.  Infrared  data  total  cloud. 

d.  Infrared  layer  amounts  and  types. 

e.  Diagnostic  information. 

5.1.3  The  Histogram  Method 

The  basic  method  in  determining  cloud  cover  is  the  histogram  method  which  is 
shown  in  an  example  in  Figure  5.4.  Let's  say  ve  have  a  cloud  over  a  water 
background  as  seen  in  step  1.  For  simplicity,  we'll  provide  the  simple, 
visual  data  case  only.  When  seen  from  a  meteorological  satellite,  the 
conditions  in  a  (approximately)  25  nm  by  25  nm  riephanalysis  gridpoint  would 
appear  as  in  step  2.  Step  3  shows  an  array  of  the  visual  brightness  values 
for  the  (approximately)  3  nm  by  3  run  pixel  grayshade  values  from  the  SGDB. 

Step  4  shows  the  resultant  histogram  for  the  frequency  of  occurrence  for  the 
possible  grayshades.  After  the  histogram  is  formed,  the  expected  background 
brightness,  here  a  5  for  a  water  background,  is  compared  to  the  histogram  and 
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all  pixels  with  values  brighter  than  the  expected  background  are  considered 
cloudy  pixels.  The  resultant  cloud/no  cloud  decision  array  for  the  pixels  is 
shown  in  step  5.  In  this  example,  we  would  end  up  with  a  41  percent  (26/64, 
rounded  up)  cloud  cover. 

With  the  infrared  processor,  the  histogram  method  is  a  little  more  complex, 
but  the  basic  principle  of  the  histogram  remains  essentially  the  same.  The 
pixel  array  for  a  nephanalyais  grid  point  is  formed,  a  histogram  of  the 
grayahades  is  developed,  all  pixels  brighter  than  the  expected  background 
brightness  for  visual  data,  or  colder  than  the  surface  temperature  for 
infrared  data,  are  considered  cloud-covered. 

5.1.4.  General  Processing  Flow 

Because  the  input  databases  are  of  varying  resolution  and  enter  the  processing 
at  varying  times,  a  general  description  of  the  flow  is  presented,  especially 
as  the  flow  is  related  to  the  resolution  and  content  of  several  of  the  input 
and  supporting  databases.  Figure  5.5  should  be  referred  to  during  this 
discussion. 

As  noted  earlier,  the  coarsest  breakdown  of  the  RTNEPH  database  is  the 
nephanalyais  box,  with  each  hemisphere  subdivided  into  an  8  x  8  array  of 
nephanalyais  boxes.  In  turn,  each  of  these  nephanalyais  boxes  is  subdivided 
into  an  8  x  8  array  of  "whole-mesh  boxes,"  and  represent  the  coarsest  grid 
resolution  of  AFGWC's  databases.  When  the  satellite  data  are  processed,  the 
flow  is  from  nephanalyais  box  to  nephanalyais  box  for  consideration  with  the 
real  decision  for  processing  being  decided  for  each  whole-mesh  box:  if  new 
satellite  data  are  contained  with  the  whole-mesh  box,  then  the  box  will  be 
processed.  The  whole-mesh  box  also  represents  the  granularity  of  the  upper 
air  temperature  databases.  A  single  temperature  value  is  assigned  to  the 
center  point  of  the  box  and  is  considered  valid  for  the  whole  box, 
approximately  a  200  nm  by  200  nm  area. 

Once  a  whole-mesh  box  has  been  considered  for  processing,  there  could  still  be 
large  areas  within  the  box  which  don't  have  new  satellite  data  for 
processing.  The  ubb  of  quarter-mesh  boxes  solves  this  problem.  Unprocessed 
satellite  data  la  retrieved  from  the  SGDB  for  a  quarter-mesh  box;  each 
whole-mesh  box  is,  as  expected,  a  4  by  4  array  of  quarter-mesh  boxes.  SGDB 
look  angles,  valid  times,  and  satellite  identifier  are  on  a  quarter-mesh  basis 
and  the  actual  satellite  data  processing  is  performed  on  the  whole 
quarter-mesh  box  if  the  box  is  considered  acceptable  for  processing.  After 
the  quarter-mesh  box  processing  decision  is  made,  each  eighth-mesh  box,  the 
finest  unit  of  the  RTNEPH  database,  is  processed  by  use  of  the  histogram 
method  and  the  resultant  cloud  parameters  are  derived  for  each  of  the 
eighth-mesh  boxes. 

5.2  Visual  Data  Processing 

Before  visual  data  can  be  processed,  several  acceptability  checks  are  made  on 
the  data  as  shown  in  Figure  5.6.  The  satellite  identifier,  valid  time  and 
daylight  flag  are  extracted  from  the  information  for  a  particular  quarter-mesh 
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Figure  5,6  The  visual  data  processing  flow,  Note  the  many  restrictions 
placed  on  visual  data  which  can  limit  Its  usefulness, 
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box.  These  items  ere  used  to  point  to  specific  locations  in  look-up  tables  so 
the  unprocessed  satellite  data  in  the  quarter-mesh  box  can  be  considered  for 
processing.  To  be  processed,  the  satellite  data  must  pass  three  criteriat 

a.  The  quarter-mesh  box  zenith  angle  must  be  less  than  a  constraining 
value  derived  from  lookup  tables.  These  lookup  tables  are  in  the  tuning 
parameters  database  for  the  Satellite  Processor  and  can  be  adjusted. 

b.  The  satellite  look  angle  must  be  less  than  or  equal  to  a  constraining 
value  also  derived  from  lookup  tables.  These  tables  are  also  in  the  tuning 
database. 

c.  The  quarter-mesh  box  data  must  be  sufficiently  newer  than  aatellite 
data  already  processed,  a  value  from  the  lookup  table  presently  set  at  70 
minutes . 

After  these  criteria  have  been  satisfied,  the  visual  data  is  processed  only  if 
the  point  meets  two  additional  criterias 

a.  The  point  must  not  be  in  the  sunglint  cone  and  the  variance  of  the 
brightness  values  is  below  a  threshold  value.  The  sunglint  cone  represents 
the  area  of  a  satellite  swath  where  the  surface  brightness  would  be  great 
enough  to  be  mistaken  for  bright  clouds.  This  is  especially  a  problem  over 
vater  areas.  The  variance  of  the  visual  brightness  values  is  computed  and  if 
large  enough,  clouds  are  assumed  to  b»  present  and  the  visual  data  is  used. 

b.  The  background  brightness  is  not  so  bright  as  to  be  mistaken  for 
clouds  in  a  visual  analysis.  Because  of  this  snow-  and  ice-covered  grid 
points  aren't  processed  by  the  visual  processor.  Snow  covered  points  are 
determined  by  the  AFGWC  snow  analysis  modal  (Hall,  1986)  while  ice  points  are 
retrieved  from  the  geography  database. 

5.2.1  Visual  Cloud  Cover  Determination 

The  only  parameter  we  can  specifically  determine  from  visual  data  alone  is 
total  cloud.  To  do  this,  the  Satellite  Processor  builds  the  histogram  for  the 
visual  data,  applies  a  cutoff  or  threshold  brightness  value,  B,  above  which 
pixels  are  considered  cloudy,  and  determines  how  many  pixels  are  indeed 
cloudy.  The  cutoff  is  a  database-defined  value  above  the  grayahade  of  the 
background  (the  background  brightness  value/  (Figure  5.7).  B  is  a  function 
of  the  specific  satellite  and  background  brightness  grayshads  and  accounts  for 
the  variability  of  the  3  nm  pixel  data  within  the  25  nm  grid  point. 

5.3  Infrared  Data  Processing. 

Infrared  data  processing  is  similar  to  visual  data  processing  under  the 
general  method  of  forming  a  histogram  of  grayshades,  selecting  a  cutoff  to 
differentiate  cloudy  from  clear  pixels,  and  determining  the  resultant  cloud 
parameters.  Just  as  the  visual  data  wee  processed  under  the  philosophy  of  any 
pixels  brighter  than  the  expected  background  were  considered  cloudy,  for 
infrared  data,  any  pixels  colder  than  the  expected  background  are  considered 
cloudy. 


GRAYSHADE 

Figure  5,7,  Generalized  Grayshade  Variance  Curve  as  a 
function  of  25  NM  Background  Brightness  Grayshades. 
This  curve  Is  the  basis  of  the  cloud/no  cloud  decisions 
made  In  the  visual  satellite  processor,  The  high 
amplitude  area  corresponds  to  coastal  and  other  hlgh- 
varlablllty  terrain  features  (from  Fye,  1978). 
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Infrared  processing,  however,  la  conplicatad  by  the  additional  requirement 
that  layere  muat  alao  be  determined*  Aa  a  reault,  the  histogram  approach 
becomea  more  complex. 

5.3.1  Infrared  Data  Proceeding  Flow 

The  proceaelng  of  infrared  data  dependa  on  a  variety  of  inpute  and  a 
proceeding  flow  ae  ahovn  in  Figure  5. ft.  Juat  aa  with  the  vlaual  data,  the 
Infrared  data  muat  meat  eeveral  criteria  to  be  proceeaed  —  namely  the  data, 
baaed  on  eenlth  angle,  look  angle  and  tlmalineea  conatralnta  aa  defined  in  the 
tuning  parameter  database. 

5.3.2  Infrared  Initialisation 

Initialisation  of  the  infrared  processing  ia  relatively  straightforward,  most 
of  the  parameters  (the  pixel  grayahada  array,  the  senith  and  look  angles,  the 
geography  type  and  the  aurface  height)  are  read  in  directly.  The  expected 
surface  temperature  (determination  of  infrared  background)  ia  derived  from 
three  inputs t  the  current  analyais,  the  previous  (3  hours  old)  analysis,  and 
the  3-hour  forecast,  aa  ahovn  in  Figure  3.9. 

5.3.3  Cloud  Determination 

The  cloud  determination  proceas  flow  for  each  gridpolnt  ia  shown  in  Figure 
5.10  beginning  with  the  histogram  and  ending  with  the  cloud  analyala. 

In  step  1,  cluatera  are  located  within  the  histogram.  Cluatera  are  initial 
groupings  of  histogram  entries  formed  under  the  following  rules: 

a.  A  cluster  begins  whenever  a  non- taro  grayahada  hlatogram  entry  follows 
a  zero  entry,  or  whenever  a  non- aero  value  follows  a  cluster  end. 

b.  A  cluatar  ends  whan  a  sero  valued  histogram  entry  is  encountered,  or 
whenever  the  alope  of  the  histogram  goes  from  decreasing  to  increasing. 

In  step  2,  cluaters  are  combined  together  to  form  modea.  Modes  are  groups  of 
clusters  with  a  sufficient  number  of  pixels  and  eventually  translate  into 
cloud  layers. 

In  atep  3,  the  coldeat  mode  temperatures  are  found.  Corrections  are  made  to 
these  mode  temperatures  to  account  for  atmospheric  attenuation  end  for 
instrument  variation.  These  corrections  consist  of: 

a.  A  bias  correction  curve.  This  is  an  empirical  correction  obtained  by 
correlating  the  aurface  temperature  with  the  infrared  sensed  temperature  in 
known  dear  air  areas.  This  curve  may  be  adjusted  upon  Insertion  of  data  from 
a  new  meteorological  satellite  into  the  SGDB  or  as  naadsd  based  on  routine 
quality  control  of  the  interpretation  and  is  in  lookup  table  format  in  the 
tuning  database. 


Figure  5,9  The  method 
by  which  the  Satellite 
Processor  determines 
the  surface  temperature. 
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IR  HISTOGRAM 


F Igure  5, 1 0  The  steps  used  by  the  Infrared  portion  of  the 
satellite  processor  to  calculate  the  cloud  parameters. 
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b.  Zenith  and  look  angle  correction*.  These  corrections  account  for 
variations  in  the  satellite  track  and  for  limb  darkening  at  high  look  anglet). 

c.  Tropical  moisture  corrections.  This  correction  accounts  for  higher 
water  vapor  attenuation  in  the  tropics.  Tho  nor them/southem  boundary  of  the 
"tropics"  range  from  23°  in  the  winter  to  32.5°  in  the  summer. 

d.  Tuning  factors.  This  is  an  empirical  correction  applied  to  a 
localized  area  to  slightly  raise  or  lover  the  modal  temperature.  These 
factors  are  adjusted  as  frequently  as  necessary. 

In  step  4,  if  there  are  more  than  four  modes,  then  they  are  recombined  until 
only  four  are  left.  Then  the  mode  temperatures  are  recalculated  as  in  step  3. 

In  step  5,  tho  heights  of  each  layer  (mode)  is  computed  by  using  the  upper  air 
temperatures  and  heights  at  standard  levels.  If  a  temperature  doesn't 
correspond  exactly  to  an  upper  air  temperature,  then  it  is  found  through 
interpolation. 

In  step  6,  the  total  cloud  and  layer  amounte  are  computed.  Total  cloud  is 
simply  the  amount  of  cloud-covered  pixels  vlthin  all  of  the  modes  divided  by 
64.  Similarly,  the  layered  amounts  are  the  total  amount  of  cloud-covered 
pixels  within  the  specific  mode  divided  by  64. 

5.3.4  Layer  Statistics 

Early  in  the  cycle  the  mean  and  variance  for  the  full  8  x  #  eighth-mesh  array 
are  calculated.  These  same  parameters  are  calculated  for  each  of  the  modes, 
equivalently  each  of  the  layers,  so  that  cloud  layer  amounts  and  types  can  be 
determined.  The  Satellite  Processor  uses  standard  mean  and  variance  formulas. 
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5.4  Cloud  Type  Determination 


The  layer  clouda  can  be  identified  an  no  type  in  the  case  of  clear  conditions, 
one  of  the  ten  types  (Table  4.5)  previously  listed,  or  as  an  unknown  type. 

The  typing  algorithm  for  the  cloud  layer  types  is  dependent  on  the 
availability  of  visual  and  infrared  data  as  well  as  on  the  expected  values  of 
mean  grayshade  and  grayshade  variance.  The  final  decision  of  the  cloud  type 
depends  on  the  visual  data  index,  an  infrared  data  index  and  a  cloud  level 
index.  This  decision  process  is  shown  by  the  lookup  table  in  Table  5.1. 

Table  5.1 

INFRARED,  VISUAL  CLOUD  INDEX 
1R  INDEX 


1  (Cumuli form)  2  (Stratiform) 


1 

(Stratiform) 

level-hi 

level-mid 

level-low 

type-CI 

typa-AC 

type-SC 

level-hi 

level-mid 

level-low 

type-CS 
type- AS 
type-ST 

level-hi 

typa-CI 

level-hi 

type-CI 

2 

level-mid 

typa-AC 

level-mid 

type-AC 

(Cumuliform) 

level-low 

typa-CU 

level-low 

type-SC 

VISUAL 

INDEX 


If  only  visual  data  are  available,  the  allowable  cloud  types  are  no  cloud  (for 
clear  conditions),  cumulonimbus  or  unknown.  If  visual  clouds  are  present,  the 
type  is  assumed  to  be  unknown  unless  the  cumulonimbus  (CB)  criteria  are 
satisfied: 

a.  The  mean  visual  grayshade  in  greater  than  the  CB  brightness  threshold 
for  the  specific  meteorological  satellite. 

b.  The  visual  data  variance  is  less  than  or  equal  to  the  CB  variance 
threshold  for  the  specific  meteorological  satellite. 

The  basic  principle  for  determining  the  type  is  that  the  more  bright  and 
uniform  the  visual  data  are,  the  morj  likely  that  the  cloud  type  is 
cumulonimbus.  When  only  visual  data  are  available,  the  lookup  table  is  not 
used  at  all. 

If  only  infrared  data  are  available,  the  lookup  table  (Table  5.1)  is  used. 

The  vleual  index  is  set  to  1|  the  infrared  index  is  2  (stratiform)  if  the 
infrared  layer's  variance  is  less  than  or  equal  to  a  (level-based,  satellite 
specific)  variance  threshold  and  1  (cumuliform) 
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otherwise;  the  level  is  based  on  whether  the  top  of  the  layer  is  in  the  low, 
middle  or  high  range.  The  one  exception  to  using  the  lookup  table  is  when  CBs 
are  being  evaluated;  if  the  top  of  the  layer  is  above  5486  meters  and  the 
infrared  variance  is  less  than  or  equal  to  an  infrared  CB  threshold,  then  the 
cloud  type  is  cumulonimbus.  Again  the  basic  principle  for  cloud  typing  is  the 
more  variable  the  infrared  data  are,  the  more  likely  that  cumuli  form  clouds 
are  being  detected. 

If  both  infrared  and  visual  data  are  available,  the  cloud  typing  becomes 
slightly  more  complex.  First,  the  Satellite  Processor  determines  the  visual 
index.  The  visual  index  is  determined  in  a  manner  similar  to  the  IR  index 
except  that  visual  brightness  variance  is  used.  It  is  1  for  stratiform  clouds 
and  2  for  cumuliform  clouds.  Then  the  Infrared  index  is  found  in  a  similar 
manner.  Once  this  is  accomplished,  the  cloud  type  may  be  found  by  using  the 
lookup  table  (Table  5.1).  As  with  the  infrared  method,  the  Satellite 
Processor  uses  the  same  check  for  determining  CBs. 

5.5  Merging  Data  into  Satellite  Analysis 

When  the  satellite  analysis  is  completed,  for  each  eighth-mesh  grid  point,  the 
following  parameters  have  been  determined: 

a.  Data  mix  (infrared,  visual  or  both). 

b.  Visual  cloud  type  (0,  1,  or  25). 

c.  Visual  total  cloud. 

d.  Infrared  total  cloud. 

e.  Data  time. 

f.  Visual  histogram  grayshade  variance, 
g  Visual  histogram  mean  grayshade. 

h.  Infrared  histogram  grayshade  variance. 

i.  For  each  layer,  the  height  of  the  top,  the  amount  and  the  type. 

J.  The  difference  between  the  surface  and  mode's  infrared  (coldest 
criteria)  temperature. 

k.  Diagnostic  information. 

These  parameters,  along  with  a  comparable  analysis  from  the  Conventional 
Processor  and  the  existing  nephanalysis,  will  be  merged  in  the  Merge  Processor 
to  produce  the  new  analysis. 
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5.6  Updating  Background  Brightness  Fields 

The  interpretation  of  clouds,  especially  from  visual  data,  is  extremely 
dependent  on  the  background  brightness  fields,  but  these  values  change  due  to 
sun  angle  changes,  reflectivity  changes,  snow  cover  changes,  etc.,  and  must 
have  a  way  of  being  updated.  The  method  for  updating  is  to  compare  the  sensed 
brightness  to  the  expected  background  brightness  and  to  let  the  background 
brightness  be  adjusted  so  that  they  approach  the  new  sensed  values  without 
straying  too  far  from  the  current  values. 

Before  the  brightness  values  are  updated,  they  must  pass  two  sets  of 
conditions  -  effectively  a  set  of  acceptability  conditions  and  a  set  of 
threshold  conditions,  To  be  considered  acceptable  for  updating,  the  grid 
point  must: 

a.  Be  a  land  or  coastal  point, 

b.  Have  visual  and  infrared  data, 

c.  Not  be  a  snow-covered  point,  and 

d.  Not  be  in  the  sunglint  cone. 

Those  criteria  assure  that  clouds,  snow,  or  sunglint  don't  affect  the  updating 
process,  If  the  grid  point  has  passed  these  acceptance  criteria,  then  several 
threshold  criteria  are  considered.  These  criteria  are  based  on  several  tuning 
parameters  which  can  be  adjusted  by  personnel  performing  quality  control  of 
the  nephanalysis.  To  be  updated,  a  grid  point  must  pass  all  the  following 
thresholds  tests: 

a.  Analyzed  visual  total  cloud  must  be  less  than  or  equal  to  a  threshold 
value  for  the  total  visual  cloud  (i.e.,  if  the  grid  point  is  relatively 
uncloudy,  visually). 

b.  There's  no  infrared  determined  cloud  or  the  analyzed  infrared  total 
cloud  is  less  than  or  equal  to  a  threshold  value  for  total  infrared  cloud. 

c.  The  visual  data  zenith  angle  is  less  than  or  equal  to  a  threshold 
value  for  the  visual  zenith  angle, 

d.  The  mean  grayshade  for  the  pixels  must  be  less  than  or  equal  to  a  mean 
grayshade  threshold. 

e.  The  difference  between  the  mean  grayshade  and  the  background 
brightness  value  must  be  less  than  or  equal  to  a  maximum  allowable  difference 
(i.e.,  don't  update  if  the  analyzed  mean  grayshade  and  existing  background 
brightness  value  are  too  different). 
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Having  passed  these  acceptance  and  threshold  checks,  the  grid  point's 
background  brightness  value  will  be  updated.  As  part  of  the  updating,  several 
parameters  are  incorporated  into  the  updating,  namely: 

a.  A  maximum  allowable  change 

b.  An  upper  limit  on  a  changed  brightness  value 

c.  A  lower  limit  on  a  changed  brightness  value 
The  updating  algorithm  then  becomes: 

a.  If  the  mean  analyzed  grayshade  is  greater  than  or  equal  to  the 
background  brightness,  then  the  new  background  brightness  «  minimum  of  upper 
limit  (b  above)  and  background  brightness  4  1/2  (mean  -  background  brightness). 

b.  If  the  mean  analyzed  grayshade  is  less  than  the  background  brightness, 
then  the  new  background  brightness  a  maximum  of  lower  limit  (c  above)  and 
background  brightness  -  1/2  (mean  -  background  brightness). 


SECTION  6.  MERGE  PROCESSOR 

6.1  Overview 

The  satellite  and  conventional  processors ,  as  noted  earlier,  provide  global 
analyses,  but  only  at  the  grid  points  where  they  processed  data.  The  Merge 
Processor  merges  these  analyses  into  the  existing  nephanalyais  database.  When 
the  Merge  Processor  completes  this  incorporation,  it  provides  an  updated 
global  nephanalysls  database.  The  merging  of  this  new  data  not  only  updates 
the  basic  parameters,  such  as  total  cloud  amount,  but  also  the  layer  source 
data  and  diagnostic  information, 

6.1.1  Inputs 

The  Inputs,  as  shown  in  Figure  6.1,  are  fairly  straightforward.  The  current 
persistence  nephanalysis  database  serves  as  the  starting  point;  the 
conventional  analysis  will  provide  input  at  only  those  grid  points  where 
conventional  data  were  actually  available;  the  satellite  analysis  provides  the 
analysis  over  those  areas  where  meteorological  satellite  data  ’’ere  available. 
If  we  consider  one  box,  as  shown  in  Figure  6.2,  we  would  have  the  full  box 
analysis  for  a  starting  point,  the  grid  points  where  conventional  reports  were 
analyzed,  and  the  area  where  newly  processed  satellite  data  were  available. 

The  geography  fields  also  are  input,  but  are  used  to  aid  in  decisions  at 
individual  grid  points  rather  than  supplying  actual  input  data. 

6.1.2  General  Process  Flow 

The  general  process  is  to  start  with  the  current  analysis  and  bring  in  a  new 
input  such  as  the  conventional  or  satellite  analysis,  and  incorporate  the  new 
data  as  processed.  Figure  6.3  shows  a  more  detailed  flow  of  this  process. 
During  the  merge  of  this  data,  decisions  are  made  whether  or  not  to 
incorporate  the  new  data  based  on  timeliness  and  data  type  considerations; 
these  considerations  will  be  discussed  in  more  detail  later.  Additionally, 
the  merge  process  will  reconcile  conflicts  between  conventional  and  satellite 
data.  When  the  Merge  Processor  is  finished,  a  complete,  updated  database  will 
exist  for  any  applications  program. 

6.1.3  Modifiable  Parameters 

Like  the  Satellite  Processor,  the  Merge  Processor  allows  some  flexibility  by 
using  easily  modified  tuning  parameters.  The  application  of  the  specific 
parameters  will  be  discussed  in  later  sections. 

6.2  Baseline  Analysis 

The  baseline,  or  starting  point,  for  the  Merge  Processor  is  the  existing 
analysis  database.  In  general,  whenever  new  data  aren't  available,  the  Merge 
Processor  will  persist  the  original  analysis.  Although  this  can  cause  the 
data  at  aome  grid  points,  particularly  near  the  equator,  to  become 
increasingly  older,  this  can  be  identified  by  querying  the  data  valid  times. 


49 


LEGEND: 

X  -  CONVENTIONAL  DATA 
□  ■  PERSISTENCE  ANALYSIS 
iiil  -  SATELLITE  ANALYSIS 


Figure  6,2  An  example  of  how  a  particular  RTNEPH  box  of  data  may 
be  merged.  The  area  where  new  satellite  data  Is  can  have  satellite 
data  and  conventional  data  to  add  to  the  persistence  analysis.  Where 
there  is  only  conventional  data,  then  that  data  is  available  to  update 
the  persistence  analysis.  If  only  persistence  data  is  available, 

it  is  persisted, 


6.3  Merging  Conventional  Data 

The  conventional  analysis,  as  noted  earlier,  provides  information  only  at 
those  grid  points  where  a  conventional  report  was  available  for  processing. 

The  Merge  Processor  will  both  reduce  and  increase  the  influence  of  this  data. 
The  reduction  occurs  when  it  excludes  data  from  consideration  because  the  data 
failed  certain  timeliness  criteria.  The  increased  influence  occurs  when 
conventional  data  ara  "spread.*'  Data  spreading,  discussed  in  more  detail 
later,  refers  to  the  use  of  a  conventional  data  report  at  grid  points  other 
than  the  specific  grid  point  to  which  the  report  was  assigned.  This  process 
allows  a  greater  spatial  use  of  conventional  data  when  no  other  data  are 
available.  This  spreading  depanda  on  the  assumption  that  conditions  observed 
by  a  surface-baaed  observer  are  moat  likely  representative  over  a  greater  area 
than  a  single  grid  point. 

6.3.1  Timeliness  and  Quality  Checks 

The  Merge  Processor  doesn't  just  insert  the  conventional  data  arbitrarily,  but 
Instead  requires  the  data  pass  some  timeliness  and  quality  checks.  Xn  the 
case  of  merging  the  conventional  data,  the  only  check  is  whether  the 
conventional  data  is  overwriting  a  "timely"  bogus,  with  "timely"  being  a 
database  defined  time.  (A  bogus  is  a  manual  modification  to  the  RTNEPH  via 
the  Bogus  Processor).  Xn  effect,  the  timeliness  and  quality  check  1st  if  the 
grid  point  doesn't  have  the  bogus  flag  set  or,  if  the  grid  point  has  been 
bogused,  but  the  bogus  is  more  than  an  acceptable  (a  tuneable  parameter) 
amount  of  time  older  than  the  valid  time  for  the  report,  then  the  conventional 
data  will  be  inserted  into  the  analysis. 

If  the  conventional  report  has  been  determined  to  be  sufficiently  timely  or 
doesn't  overwrite  a  boguaed  point,  some  quality  checks  and  correaponding 
corrections,  if  needed,  are  performed,  specifically: 

a.  Ia  the  total  cloud  zero  with  non-zero  layers?  If  ao,  replace  the 
total  cloud  with  the  sum  of  the  layers. 

b.  Ia  any  layer  larger  than  the  total  cloud  value?  If  so,  replace  the 
layer  amount  with  the  total  cloud  rounded  up  to  the  nearest  5  percent. 

c.  Is  the  total  cloud  greater  than  the  sum  of  the  layers?  If  so,  replace 
the  top  layer  with  the  total  cloud  rounded  up  to  the  nearest  5  percent. 

Although  there  is  no  direct  check  for  total  cloud  greater  than  zero  but  with 
zero-valued  layer e,  this  ia  effectively  cheeked  in  the  third  check.  However, 
these  errors  seldom  occur.  Although  these  checks  and  corrective  measures  may 
not  be  very  sophisticated,  they  reduce  the  magnitude  of  the  inconsistencies. 

By  the  time  the  Merge  Processor  completes  quality  and  timeliness  checks, 
updated  grid  points  contain  new  values  for: 

a.  Present  weather 
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to.  Visibility 

c.  Total  cloud 

d.  Layers  based  on  conventional  data 

e.  Layer  source  data  (reflecting  RAOBs ,  AIREFs,  or  surface  reports  only) 

f.  Diagnostic  entries  fort 

(1)  Beat  report 

(2)  Type  of  best  report  (RAOB,  AIRIP,  surface  report) 

(3)  "Unset"  bogus  flag  if  overwritten 

(4)  Hase  override,  if  applicable  from  the  Conventional  Proceasor 

These  new  values  exist  at  the  particular  grid  point  only,  and  must  then  be 
considered  for  "spreading". 

6.3.2  Determining  the  Spreading  Distance 

The  spreading  distance  is  based  on  the  principle  that  a  conventional  report 
(i.e.,  observation  from  other  than  a  meteorological  satellite,  usually 
surface-based)  represents  an  area  greater  than  Just  one  grid  point.  Also,  the 
higher  the  cloud  layer,  the  larger  the  ares  over  which  the  report  can  be 
considered  repreaentative.  The  RTRBPH  allows  seven  spread  distances  (tunable) 
baaed  on  the  following  seven  criteria! 

a.  Lowaat  baas  is  less  than  2000  m 

b.  Lowaat  baae  is  between  2000  m  and  5000  m 

c.  Lowest  base  is  greater  than  5000  m 

d.  Grid  point  la  clear 

e.  Conventional  data  had  missing  base 

f.  Coastal  grid  point  spreading  to  land  points  for  cumulus  type  clouds, 
or, 

g.  Water  grid  point  spreading  to  land  or  coast. 

6.3.3  Determining  Grid  Points  To  Spread  To 

Up  to  now  we've  developed  a  set  of  meteorologically  consistent  data  at  a  grid 
point  and  the  array  (a  set  of  grid  points)  to  consider  for  spreading  the 
data.  Row  we  consider  each  of  the  grid  points  in  this  array.  The  Merge 


Processsor  calculates  the  distance  from  the  particular  grid  point  to  the  best 
report  grid  point.  This  radial  distance  will  be  used  whenever  a  grid  point  is 
within  the  scan  radius  of  more  than  one  best  report. 

Once  the  Merge  Processor  determines  the  spread  radius,  it  will  compare  the 
distance  from  the  best  report  grid  point  to  the  considered  grid  point,  using 
the  following  criteria: 

a.  If  the  distance  is  greater  than  the  allowable  spread  radius,  the  best 
report  data  won't  be  spread  to  the  considered  grid  point. 

b.  If  the  considered  grid  point  is  within  the  allowable  spread  radius, 
several  other  checks  are  considered: 

(1)  If  no  data  have  been  spread  to  the  point  yet,  so  ahead  and  spread 
to  that  point. 

(2)  If  data  have  already  been  spread  to  the  point  from  a  previously 
considered  best  report,  then: 

(a)  If  the  distance  from  the  current  best  report  is  greater  than 
from  the  previously  used  best  report,  don't  spread. 

(b)  If  the  distance  from  the  current  best  report  is  less  than 
the  previously  used  beat  report,  spread. 

(c)  If  the  distances  ire  equal,  yet  another  set  of  criteria  are 

considered: 

X.  The  newest  of  the  two  best  reports  is  spread  to  the  grid 
point  under  consideration. 

2..  If  the  two  best  reports  are  equally  timely,  the  least 
cloudy  one  ia  used. 

2.  If  the  two  best  reports  are  equally  cloudy,  the  one  with 
the  greatest  vlaibility  is  used, 

4.  If  no  tie  breaker  arrived  by  now,  just  retain  the  data 
already  spread  to  the  considered  grid  point! 

6.3.4  Spreading  the  Data 

At  this  point  a  conaistent,  complete  set  of  parameters  have  been  determined  at 
the  grid  point  with  the  beat  report,  and  the  array  of  grid  points  to  which 
these  data  can  be  spread  have  elso  been  determined.  One  last  check  is  made 
though,  before  data  are  spread  to  the  point.  If  the  point  has  a  bogus  "newer" 
(i.e.,  by  a  database  defined  parameter)  than  the  best  report,  don't  apread  to 
the  point. 
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When  the  actual  spreading  of  the  data  ia  complete,  there  are  atlll  some 
modi fleet Iona  to  the  data  to  be  made,  namely: 

a.  If  the  base  of  a  layer  is  lover  than  the  terrain  at  the  spreaded  grid 

point,  the  base  is  replaced  by  the  terrain  height. 

b.  If  the  top  (as  well  as  the  base)  is  lover  than  the  terrain  at  the 

spreaded  grid  point,  don't  spread  that  particular  layer  to  the  grid  point 
(this  effectively  allows  stratus  not  to  spread  onto  high  terrain,  for  example). 

Similarly,  if  some  data  are  still  missing,  thia  problrm  will  be  adjusted: 

a.  If  the  cloud  layer  type  la  missing,  it  will  be  considered  stratus. 

b.  If  the  cloud  top  la  miaaing  (a  frequent  situation  when  considering 

surface-baaed  reports)  the  new  (estimated)  top  of  the  layer  will  be 

top  «  base  +  thickness 

where  the  thickness  ia  a  function  of  the  cloud  type  aa  shown  in  Table  6.1: 

Table  6.1 

DEFAULT  THICKNESSES  BY  CLOUD  TYPE 

Type  Thickness  (meters) 


<1> 

Cumulonimbus 

6500 

(2) 

Stratus 

300 

<3) 

Stratocumulus 

1800 

(4) 

Cumulus 

2000 

(5) 

Altoatratus 

1000 

<6) 

Altocumulus 

1800 

(7) 

Nimbostratus 

2000 

(8) 

Cirrus 

1000 

(•> 

Cirrostratus 

1800 

(10) 

Cirrocumulus 

2000 

If  the  Merge  Processor  estimates  the  layer  top,  it  sets  the  estimated  top  flag 
In  the  source  information  for  the  applicable  layer.  The  diagnostic  data  will 
be  updated  at  the  apread-to  grid  point  to  reflect  the  diagnostic  information 
at  the  source  point.  The  only  difference  is  the  spread-to  grid  point  will 
have  the  spread-to  flag  set.  The  valid  time  of  the  data  at  the  spread-to  grid 
point  will  be  that  of  the  "beat  report"  which  was  used  for  the  spreading. 

6.4  Merging  Satellite  Data 

The  incorporation  of  conventional  data  vers  relatively  simple:  the  decision 
were  generally  based  only  on  whether  the  data  considered  were  newer  than  data 
already  present.  The  incorporation  of  satellite  data  includes  not  only  time 
checks  for  the  relative  currentnesa  of  the  data,  but  also  "exception"  rules 
based  on  the  special  characteristics  of  meteorological  satellite  data,  both 
visual  and  infrared. 
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6.4.1  Timeliness  and  Data  "Quality"  Checks 

Ao  with  the  conventional  data,  the  timeliness  of  the  satellite  data  is  a  major 
factor  in  any  decialon  to  include  the  satellite  analyais  in  the  final 
nephanalysis  database.  The  decialon  rules  on  a  grid  point  basis,  are  as 
follows  t 


a.  If  tha  current  analysis  includes  satellite  data  and  the  satellite  data 
under  consideration  are  more  than  70  minutes  (adjustable)  older  than  the 
current  analysis,  then  it's  assumed  the  satellite  data  have  already  bean 
processed,  possibly  being  tha  same  data  aa  already  exists  in  the  analysis. 
Satellite  data  failing  this  check  are  rejected  for  processing. 

b.  If  the  satellite  data  are  more  than  a  database-specified  number  of 
hours  newer  than  the  analyaia,  then  the  current  analysis  is  deemed  to  be 
excessively  old  and  is  directly  replaced  by  the  satellite  data. 

o.  If  the  current  analyaia  is  older  than  the  satellite  data,  again  by  a 
database  specified  number  of  hours,  but  la  not  "excessively"  older,  then  lower 
clouds  contained  in  tha  current  analysis  may  be  retained. 

The  decialon  whether  tha  satellite  data  aro  to  be  included  is  summarised  in 
Figure  6.4. 

We're  essentially  left  with  three  cease  to  describe  further: 

a.  The  satellite  data  completely  overwrite  the  current  analysis. 

b.  The  satellite  data  are  newer  than  the  current  analysis,  but  not  ao  new 
as  to  preclude  retaining  or  persisting  the  low  clouds. 

c.  The  satellite  data  and  the  current  analysis,  which  contained 
conventional  data,  aro  both  "timely", 

6,4.2  Satellite  Data  Incorporated  Directly 

Recall  the  satellite  analysis  has  values  for  visual  total  cloud  and  Infrared 
total  cloud.  The  Merge  Processor  uses  these  two  independent  values  to 
determine  the  analysis  values  when  the  satellite  data  complotely  overwrite  the 
current  analysis.  These  amounts,  plus  the  type  of  satellite  data  considered, 
are  procesaad  aa  follows: 

a.  If  only  Infrared  data  are  available,  the  layers  derived  from  the 
infrared  data  are  used  and  the  total  cloud  is  the  infrared-derived  total  cloud. 

b.  If  only  visual  data  are  available,  another  decision  is  applied:  if 
tha  visual  total  is  zero,  the  point's  data  reflect  clear  conditions;  if  the 
visual  total  is  not  zero,  then  the  point  is  left  clear  and  the  Merge  Processor 
seta  a  diagnoatic  flag  to  Indicate  this  case. 
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Figure  6 A  The  decision  tree  for  using  satellite  data 
In  the  Merge  Processor. 


— j.' 


c.  If  both  infrared  and  visual  data  exist,  the  Merge  Processor  uses  a  new 
decision  tree: 

visual  total  visual  total 

>0  »0 

infrared  total  store  larger  total  denote  high  cloud 

>0  cloud.  Add  a  stratus  layers  as  thin2 

layer  if  visual  total 
cloud  is  "significantly" 
larger  than  IR  total 
cloud . 1 


infrared  total  Form  a  stratus  layer1  clear 

■I 0 

1  This  rule  represents  the  fact  that  the  infrared  data  often  cannot 
detect  low  clouds  because  the  temperatures  of  the  stratus  top  are 
close  to  or  even  warmer  than  the  ground  temperature.  The 
characteristics  of  this  formed  layer  are: 

amount  ■  difference  between  the  visual  total  cloud  and  the 
infrared  total  cloud 

type  ■  stratus 

base  m  terrain  height  +  "stratus-base"  (database  parameter) 

top  ■  base  +  200  m 

Additionally,  diagnostic  flags  for  estimated  base,  estimated  top  and 
visual  data  will  be  set. 

Even  this  rule,  however,  has  a  variation  if  there  are  already  four 
layers:  the  lowest  layer  amount  will  be  increased  so  that  it  is  the 
minimum  of  "total  cloud"  and  "layer  A  amount  plus  the  difference 
between  the  visual  and  Infrared  total  amounts";  the  layer  A  type  is 
incremented  by  10  to  show  a  stratus  or  fog  layer  when  four  layers 
already  exist. 

2  This  rule  reflects  the  fact  that  thin  cirrus  will  be  detected  by  the 
Infrared  sensor,  but  the  visual  return  may  detect  no  clouds  or  a  cloud 
layer  more  like  haze  than  cloud.  Ho  correction  is  made  to  the  cloud 
thickness;  a  +1  offset  is  added  to  the  layer  amount. 

6. A. 2.1  Layer  Adjustments 

With  the  above  processes  complete,  the  analysis  has  a  set  of  layers  derived 
from  the  satellite  data.  However,  each  layer  amount  is  the  percentage  of  the 
view  filled  by  that  particular  layer  (as  shown  in  Figure  6.5)  rather  than  the 
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Figure  6.5  Cloud  layer  amounts  before  spreading 
in  the  Merge  Processor. 
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Figure  6.6  Cloud  layer  amounts  after  spreading 
in  the  Merge  Processor. 


true  layer  amount.  To  calculate  the  "true"  layer  amount,  it 'a  assumed  each 
layer  occupies  approximately  the  same  percentage  of  the  total  sky  as  it 
occupies  in  the  unobscured  sky  (as  shown  in  Figure  6.6). 

6.4.3  Satellite  Data  Merged  Into  Analysis 

When  the  persistence  analysis  is  new  enough  (leas  than  four  hours),  the  Merge 
Processor  must  merge  satellite  data  into  the  persistence  analysis  instead  of 
overwriting  it. 

6. 4. 3.1  Low  Cloud  Retention 

Before  the  satellite  data  can  be  merged,  the  Merge  Processor  seeks  to 
eliminate  high  and  middle  clouds  from  the  persistence  analysis.  It  will  do 
this  if  either  of  the  following  conditions  can  be  met: 

a.  If  the  persistence  analysis  is  at  least  70  minutes  older  than  the 
satellite  data,  or 

b.  If  there  are  no  satellite  layers  in  the  persistence  analysis. 

Assuming  either  of  the  above  conditions  are  met,  the  Merge  Processor  will 
strip  high  and  middle  clouds  from  the  persistence  analysis.  The  justification 
for  doing  this  is  that  the  satellite  data  is  inherently  better  at  detecting 
higher  clouds  than  low-level  clouds.  Otherwise,  the  Merge  Processor  may  loBe 
a  low  cloud  layer  that  the  satellite  analysis  missed,  but  the  conventional 
data  had  detected. 

6. 4. 3. 2  Merging  Satellite  Data  with  the  Analysis 

The  Merge  Processor  can  now  merge  the  satellite  data  into  the  analysis.  The 
merging  is  rather  simple  —  the  satellite  layers  are  inserted  into  the 
database.  However,  if  visual  satellite  data  is  the  only  data  source,  then 
it's  only  used  to  adjust  the  total  cloud  in  the  persistence  analysis  since 
there's  no  layer  information  contained  in  it. 

6.4.4  Cloud  Layer  Adjustment 

The  internal  arrays  in  the  Merge  Processor  can  hold  up  to  eight  cloud  layers. 
At  this  point,  layers  must  be  reduced  to  no  more  than  four  layers.  If  more 
than  four  layers  exist,  the  Merge  Processor  begins  looking  for  compatible 
layers  to  merge  within  a  specified  scan  radius.  The  scan  radius  is  the 
distance  between  the  lower  layer's  top  and  the  higher  layer's  base.  Layers 
are  merged  according  to  their  height  group  and  CB  clouds  are  excluded  from  the 
merging.  If  for  instance,  the  distance  between  a  layer  of  AS  and  AC  was 
within  the  scan  radius,  the  two  layers  would  be  joined  together.  This  new 
layer  would  carry  the  base  of  the  lower  layer,  the  top  of  the  higher  layer, 
the  higher  type  number  (see  Table  4.5),  and  the  amount  of  the  layer  with  the 
greatest  amount  unless  the  sum  of  the  two  layers  is  less  than  the  total  cloud 
value.  In  that  case,  the  Merge  Processor  will  use  the  sum  of  the  two  layers. 


If,  after  one  pass,  there  are  still  more  than  four  layers,  then  the  scan 
radius  is  incremented  and  the  process  repeated.  When  the  Merge  Processor 
finishes  the  layer  merging,  the  analysis  is  complete  and  is  stored  In  the 
database. 


SECTION  7.  BOGUS  PROCESSOR 


7.1  Bogus  Processor  Concept 

As  noted  In  earlier  sections,  interpretation  errors  can  occur.  The  most 
common  misinterpretation  Is  due  to  the  difficulties  of  analyzing  fog  or 
stratus)  especially  over  snow-covered  backgrounds.  To  compensate  for  this, 
the  capability  to  correct  the  database  after  detailed  quality  control  has  been 
provided  by  the  unfortunately  named  Bogus  Processor.  This  processor  allows  a 
database  analyst  to  perform  a  near  real-time  correction  in  conjunction  with 
near  real-time  quality  control,  The  Bogus  Processor  can  be  executed 
Independent  of  the  other  processors  and  is  used  by  the  available  personnel  and 
computer  resources  to  conduct  as  much  quality  control  as  is  desired.  Because 
the  Satellite  and  Merge  Processors  operate  on  a  quarter  orbit  by  quarter  orbit 
basis,  bogusing  is  also  done  on  a  quarter  orbit  by  quarter  orbit  basis. 

7.2  Method 

The  method  of  meteorological  satellite  data  input  has  historically  been  a 
function  of  the  hardware  available  at  the  Air  Force  Global  Weather  Central. 

In  1987,  the  procedure  was  to  define  the  perimeter  of  the  area  to  be  changed 
by  using  a  cursor  on  a  digitizing  table.  When  AFGWC'a  new  Satellite  Data 
Handling  System  (SDHS),  a  system  of  minicomputers  and  graphics  terminals, 
becomes  operational,  the  method  will  be  to  define  the  area  to  be  bogused  on  a 
graphics  terminal.  In  addition  to  the  perimeter  definition,  the  new  cloud 
parameters  are  input.  Up  to  ten  parameters  may  be  used  in  the  bogused  area. 
However,  as  will  be  discussed  in  more  detail  later,  any  inputs  will  eventually 
be  constrained  by  the  database  itself;  e.g.,  a  maximum  of  four  layers  will  be 
retained  at  a  grid  point. 

After  the  perimeter  is  defined,  the  grid  points  on  and  within  this  perimeter 
are  determined;  these  are  the  grid  points  at  which  the  input  parameters  will 
be  proceaaed.  The  grid  points  are  determined  by  a  variant  of  the  common 
screen-fill  or  "paint"  programs  and  warrants  no  further  discussion. 

Once  the  applicable  grid  points  have  been  determined  and  the  new  database 
parameters  input,  the  continuation  of  the  Bogus  Processor  depends  on  the 
option  selected. 

7.3  Bogus  Options 

Three  possible  bogus  options  can  be  applied.  The  first  is  to  insert  new 
weather  and  visibility  values  at  a  grid  point,  a  rarely  used  option.  The 
second  option,  also  rare,  is  to  insert  a  totally  new  cloud  layer  by  defining  a 
cloud  base  and  top  as  well  as  a  type  and  amount.  The  most  frequently  used 
option,  the  third,  is  to  define  a  cloud  type  and  amount  for  the  new  layer,  and 
to  use  a  set  of  default  values  for  the  base  and  top.  The  new  data  are 
processed  into  the  database  and  then,  depending  on  the  option  selected, 
inconsistencies  are  corrected  and  diagnostic  information  is  updated. 


Some  constrainte  on  the  eventual  "appearance"  of  the  database  result  from  two 
pre-processing  activities  on  the  inputs.  First,  the  cloud  amounts  are  usually 
entered  in  eighths  and  converted  into  percents  as  shown  in  Table  7.1. 


Table  7.1 

CLOUD  AMOUNT  CONVERSIONS 


Cloud  Amount,  fElahtha^ 


Converted  Percent 


o 

1 

2 

3 

4 

5 

6 

7 

8 


0 

15 

25 

40 

50 

65 

75 

90 

100 


Likewise,  the  visibility  values  are  entered  in  kilometers  and  encoded  as  shown 
in  Table  7.2,  which  represents  WMO  Code  4377. 


Table  7.2 

VISIBILITY  CONVERSIONS 


Input  Visibility  (km) 

Code  Value 

(range) 

.1 

00  (00) 

.1  -  5.0 

vis  x  10.1 

(01-50) 

6.0  -  30.0 

vis  +  50 

(56-80) 

30  -  70 

(vis/5)+74 

(80-88) 

70  -  89 

(89) 

These  pre-processing  conversions,  especially  the  cloud  amount  conversion,  can 
cause  an  increased  frequency  of  occurrence  of  certain  values  and  should  be 
considered  whenever  any  statistical  summaries  of  the  nephanalyslo  database  are 
done. 


7.3.1  Weather/Visibility  Bogus 

Bogusing  the  present  weather  and  visibility  parameters  is  a  straightforward, 
but  infrequently  used  option.  The  basic  operational  flow  is  tot 

a.  Replace  the  database  present  weather  value  with  the  bogused  present 
weather. 


b.  Replace  the  database  visibility  with  the  bogused  visibility. 

c.  Set  the  bogus  indicator  in  the  diagnostic  word. 

d.  Cancel  out  the  "second  weather"  indicator  in  the  diagnostic 
information  if  the  most  current  data  at  the  grid  point  were  more  than  four 
hours  old  or  if  weather  types  05  (haze)  or  40-49  (fog  types)  were  bogused. 


The  firat  three  atepa  merely  update  the  databaae  and  Indicate  that  the  grid 
point  data  contain  boguaed  information.  The  laat  step  is  to  assure  that  the 
primary  present  weather  and  the  Becond  weather  parameters  don't  both  reflect 
the  existence  of  fog  or  haze  and  that  the  existence  of  fog  or  haze  1b  not 
retained  too  long  In  the  databaae  (i.e.f  if  present  weather  is  intentionally 
changedi  then  fog  or  haze  shouldn't  be  retained  too  long).  The  valid  time  of 
the  data  is  not  modified  to  reflect  the  boguaingi  but  will  continue  to  reflect 
the  time  of  the  cloud  information. 

7.3.2  Type/Amount/Base/Top  Bogus 

Inserting  entirely  new  cloud  layers  into  the  database  is  the  primary  purpose 
of  bogusing.  The  moat  definitive  option  is  to  input  the  full  act  of 
layer-defining  parameters t  cloud  type,  amount,  baae  and  top.  Thia  option, 
although  not  as  straightforward  aa  the  vialbllity/weather  option,  still  can  be 
reduced  to  a  aet  of  basic  functions.  After  the  bogus  data  have  been  input, 
several  processes  occur,  namely t 

a.  Clear  out  "old"  low  (middle  or  high)  layers  if  low  (middle  or  high, 
respectively)  layers  are  to  be  inserted. 

b.  Insert  the  new  set  of  bogused  cloud  layers. 

c.  Sort  the  new  set  of  layers  in  descending  order  with  the  layer  with  the 
highest  base  being  the  firat  layer. 

d.  Merge  layers  until  no  more  than  four  layers  remain,  calculating  new 
layer  parameters  for  the  layers  created  in  this  merge  process. 

e.  Recalculate  the  total  cloud  amount  based  on  the  final  (up  to  four) 
cloud  layers. 

f.  Update  the  diagnostic  information  in  the  database. 

The  separate  steps  warrant  further  discussion.  Before  any  new  layers  can  be 
inserted,  the  Bogus  Processor  will  eliminate  any  "appropriate"  layers  in  the 
pre-bogus  database.  An  "appropriate"  layer  is  one  in  the  same  grouping  (i.e., 
low,  middle  or  high).  For  example,  if  a  low  cloud  type  is  to  be  inserted, 
previously  existing  low  clouds  will  be  eliminated  prior  to  inserting  the  new 
low  cloud  layers.  Thia  process  can  be  done  only  once  for  each  of  the  low, 
middle  or  high  groups,  on  the  first  insertion)  this  precludes  newly  bogused 
low  (or  middle  or  high)  layers  from  eliminating  the  other  bogused  layers  of 
that  same  group  otherwise  the  bogused  areas  would  effectively  be  restricted  to 
one  low,  middle  or  high  layer. 

The  insertion  of  the  new  layers  is  essentially  just  to  put  them  into  an  array 
of  layers  to  be  sorted  and  eventually  reduced  to  at  most  four  layers.  As  part 
of  this  process  the  bogused  bases  and  tops  are  encoded  to  database  values  (see 
Table  4.5)  and  added  to  the  terrain  elevation  at  the  point.  The  bogused  bases 
and  tops  are  "AGL"  values  and  reconverted  to  MSL  in  this  step. 


65 


Sorting  the  layers  is  a  simple  process  and  requires  no  further  discussion.  If 
more  than  four  layers  exist,  then  layers  must  be  merged  to  form  a  maximum  of 
four  new  layers.  This  process  will  be  described  later. 


Finally,  a  new  total  cloud  amount  is  calculated  from  the  new  and  remaining 
original  layers.  This  process  will  be  discussed  later. 

7. 3. 2.1  Cloud  Layer  Merging 

Since  up  to  10  cloud  layers  theoretically  can  exist  from  the  bogus  inputs, 
layers,  on  occasion,  muat  be  merged  to  reduce  the  number  to  no  more  than 
four.  The  merging  of  layers  is  based  on  fairly  straightforward  criteria.  The 
layers  must  be  of  similar  cloud  types  and  must  be  close  together  (in  the 
vertical).  From  these  criteria,  the  following  rules  are  established! 

a.  High  cloud  types  can  be  merged  only  with  other  high  cloud  types. 
Likewise  for  middle  and  low  clouds. 

b.  Cumulonimbus  clouds  will  not  be  merged. 

c.  The  layers'  bases  must  be  separated  by  no  more  than  an  amount  based  on 
the  layer  (potentially  a  different  separation  criterion  for  low,  middle  and 
high  cloud  layers).  The  method  is: 

(1)  Start  with  the  two  highest-base  layers  and  a  set  of  separation 
criteria  (e.g.,  1000  meters  for  high  clouds). 

(2)  If  the  layers  are  both  high  and  the  bases  differ  by  no  more  than 
the  high  cloud  separation  criteria,  merge  the  two  high  layers  into  a  new  high 
layer;  likewise  if  the  two  layers  were  middle  (or  low)  and  if  the  middle  (or 
low)  separation  criterion  were  mat,  marge  the  two  to  form  a  new  (middle)  or 
high  layer. 

(3)  If  all  layers  have  been  considered,  but  more  than  four  layers 
still  exist,  increase  the  three  separation  criteria  and  repeat  step  2.  Keep 
increasing  the  acceptable  separations  until  only  four  layers  exist. 

With  this  procedure,  the  number  of  layers  will  be  reduced,  but  if  any  low 
(middle  or  high)  layers  existed,  then  at  least  one  low  (middle  or  high)  layer 
will  be  retained. 

When  layers  are  merged,  the  newly-formed  layers  take  on  some  of  the  qualities 
of  the  layers  which  were  merged: 

a.  The  new  layer  type  is  the  type  of  the  cloudier  of  the  two  merged 
layers;  for  equally  cloudy  layers,  the  type  is  that  of  the  higher  base  layer. 

b.  The  amount  ia  the  cloudier  of  the  two  merged  layers;  a  "4-2"  offset 
will  define  the  layer  as  a  layer  resulting  from  a  merge  (i.e.,  a  47  percent 
cloud  cover  layer  in  the  database  ia  actually  a  45  percent  cloud  cover  layer 
which  resulted  from  a  merger  of  two  layers). 
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gs. 


c.  The  new  base  to  the  lower  of  the  bases  of  the  two  cloud  layers. 

d.  The  new  top  is  the  higher  of  the  tops  of  the  two  cloud  layerB. 

7. 3. 2. 2  Total  Cloud  Calculation 

After  bogused  layers  have  been  Inserted  and  merged  as  necessary,  a  new  total 
cloud  amount  must  be  calculated  to  be  consistent  with  the  new  layers.  The  new 
total  cloud  is  determined  by  looping  through  each  layer  using: 

Total  cloud  ■  max  (a,b)  +  (1-max  (a,b))  *  min  (a,b)  *N,  (6) 

where  a  is  the  current  layer,  b  is  the  total  cloud  and  N  is  a  vertical  scaling 
factor.  Total  cloud  initially  is  set  to  zero,  but  its  updated  value  is 
retained  through  the  layer  looping. 


7,3.3  Type/Amount  Bogus 

The  third  available  option  is  to  define  the  cloud  type  and  amount  only.  This 
is  the  most  frequently  used  option.  In  this  case,  the  base  and  top  are 
assigned  by  cloud  type  according  to  Table  7.3. 

Table  7.3 

DEFAULT  CLOUD  BASE  AND  CLOUD  TOP  HEIGHTS 


Cloul  Type.- (coda) 

EACUL-Iffl) 

IflP-illO 

Cumulonimbus  (1) 

915 

9157 

Stratus  (2) 

152 

458 

Stratocumuius  (3) 

762 

1524 

Cumulus  (4) 

915 

2134 

Altostratus  (5) 

2135 

3353 

Nimbostratua  (6) 

1829 

3658 

Altocumulus  (7) 

2439 

4268 

Cirrostratus  (8) 

5487 

8231 

Cirrocumulus  (9) 

6097 

8536 

Cirrus  (10) 

6097 

8536 

After  the  default  bases  and  tops  are  incorporated  with  the  types  and  amounts, 
the  process  is  the  same  as  in  the  type/amount/base/top  option. 

7. A  Limitations  of  the  Bogus  Process 

Presently,  AFGWC  doesn't  have  the  hardware  to  bogus  every  quarter  orbit  of 
data.  Therefore,  only  about  one  out  of  every  four  quarter  orbits  may  be 
bogused.  However,  when  SDHS  comes  on  line  in  1988,  AFGWC  may  be  able  to  bogus 
at  least  three  of  every  four  quarter  orbits. 


SECTION  8.  DATABASE  CONTENTS 


Aside  from  recognising  the  specific  parameters,  a  database  user  should 
recognize  the  deviation,  meaning,  and  limitations  of  those  specific 
parameters.  This  section  will  address  those  issues,  but  will  not  describe  the 
specific  database  "word"  structure.  Any  user  of  the  RTNEPH  database  should 
obtain  the  specific  database  format  from  Air  Force  Global  Weather  Central  or 
U8AFETAC.  The  database  conteins  four  basic  groups  of  data:  the 
veather/vislbility/total  cloud  group,  layer  source  data,  layer  data,  and 
diagnostic  information.  The  data  items  and  processor  Influences  are  described 
in  each  section  as  well. 

8.1  Weather/Vislbillty/Total  Cloud/Valid  Time  Information 

This  group  essentially  provides  the  moat  general  information  available  at  the 
grid  point.  The  weather  value  is  the  WHO  Code  4677  value  (Table  4.2).  The 
visibility  is  in  WMO  Code  4377  as  shown  in  Table  7.2.  Total  cloud  is  in 
percent  increments  from  00  (clear)  to  100  (overcast).  Valid  time  is  a  coded 
deviation  from  the  reference  time  as  shown  in  Table  8.1.  The  parameter/ 
processor  relationships  are  shown  in  Table  8.2. 

Table  8.1 

TINE  FLAG  DEFINITIONS 

Meaning 

The  newest  data  at  the  gridpoint  is  this  many  hours  older 
than  the  data  reference  time. 

The  newest  data  at  the  gridpoint  is  more  than  229  hours 
older  than  the  data  reference  time. 

The  number  of  hours  newer  than  data  reference  time  -  230 
(240  is  10  hours  newer). 

Data  is  more  than  24  hours  newer  than  the  data  reference 
time. 


Coda 

0-229 

230 

231-254 

225 


Table  8.2 

PARAMETBR/PROCESSOR  RELATIONSHIPS 


Processor:  Conventional  Satellite  Merge 


Weather  source 

Paramter:  Visibility  source 
Total  Cloud  source 
Time  source 


modify  (1) 
modify  (1) 
source  (4)  modify  (2) 

source  modify  (3) 


Bogus 

source 
source 
modify  (2) 
modify  (3) 
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(1)  The  Merge  Processor  will  delete  veather/vialbllity  information  when 
data  haa  failed  a  timellneaa  check  or  when  aatelllte  data  overrides. 

(2)  The  Merge  Proceaaor  will  recalculate  total  cloud  from  resultant 
combinations  of  satellite  and  conventional  layers.  The  Bogus  Processor  will 
calculate  new  total  cloud  based  on  bogusad  layers. 

(3)  The  Marga  and  Bogus  Procaaaora  will  modify  the  valid  time  baaed  on 
time  of  newest  data  source  used  in  cloud  calculations. 

(4)  The  Satellite  Proceaaor  will  provide  both  an  infrared  and  visual  total 
cloud,  depending  on  the  availability  of  these  data. 

As  be fora,  the  layer  parameters  are  also  influenced  by  the  individual 
procaaaora  as  shown  in  Table  8.3. 

Table  8.3 

LAYER  PARAMETER/PROCESSOR  RELATIONSHIPS 


Processor! 

Conventional 

Satellite  (2) 

Merge 

Bogus 

Amount 

source 

source 

modify  (1) 

source 

Parameter i  Type 

source 

source 

modify  (1) 

source 

Base 

source 

modify  (1) 

source 

Top 

source 

source 

modify  (1) 

source 

(1)  Aa  always,  the  Marge  can  modify  a  layer  in  the  merging  process; 
modification  could  be  delation,  change,  or  keep  "as  la". 

(2)  The  Satellite  Processor  actually  provides  two  sets  of  information, 
baaed  on  availability  of  visual  and  Infrarad  data. 

8.2  Cloud  Layer  Information 

Cloud  layer  information  is  provided  for  up  to  four  layere.  Specifically 
each  layer  will  be  repreaented  by  amount,  cloud  type,  base  and  top  aa  shown  in 
Table  8.4. 


Table  8.4 

CLOUD  LAYER  INFORMATION 
Pamaelir  Range  Comments 


Amount  0-100(X) 


Type  0-25 


In  5X  increments,  except  a  +1  offset 
will  Indicate  a  thin  layer  (e.g.,  51  » 
a  thin  layer  with  SOX  coverage).  A  + 2 
offset  will  indicate  a  layer  that  was 
formed  solely  to  meet  the  four  layer 
constraint.  A  +  3  offset  ia  possible 
if  the  layer  is  a  thin,  merged  layer. 

See  Table  4.5 
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Baa* 


0-255 


Saa  Tabla  4.4 


Top  0-255  Same  as  for  base 

8.3  Layer  Source  Information 

Along  with  tha  parameter*  deacribing  the  meteorological  propertlea,  the  RTNEPH 
provldaa  data  on  tbe  aotjrcae  of  the  data.  Thia  information  la  eapacially 
uaeful  in  quality  control  of  the  model  algorithm!  aa  well  aa  for  analyata 
ualng  the  RTNEPH  databaae  for  atudiea.  The  aource  data  are  a  eat  of  yea/no 
indlcatora  (or  "flaga")  for  whether  the  following  were  the  data  aourcea  for 
the  apeciflc  layer* t 

a.  Low  cloud  peraiated)  indicate!  low  elouda  ware  retained  when  the  Merge 
Proceaaor  atrlpped  high  and  middle  level  elouda.  Sea  Section  6. 4. 3.1. 

b.  Eatlmatad  baae)  occura  whan  a  layer  top  ia  known,  but  the  baaa  ian't. 
The  baae  la  than  eatlmatad  by  ualng  the  top  and  a  default  thlckneaa. 

c.  Eatlmatad  top)  occura  when  a  layer  baa*  ia  known,  but  the  top  lan't. 

The  top  ia  then  eatlmatad  by  ualng  the  baae  and  a  default  thlckneaa. 

d.  Beat  report  from  PIREP  data)  PZREP  data  waa  uaed  to  fora  the  cloud 
layer. 

e.  Beat  report  from  RAOB  data)  RAOB  data  waa  uaed  to  fora  the  cloud  layer. 

f.  Beat  report  from  aurface  data)  aurfaca  data  waa  uaad  to  form  the  cloud 
layer. 

g.  Vlaual  aatellite  data)  vlaual  aatellite  data  waa  available  for 
detection  of  the  layer. 

h.  Infrared  aatellite  data)  infrared  aatellite  data  waa  available  for 
detection  of  the  layer. 

For  a  particular  layer,  more  than  one  aource  could  be  denoted.  For  example,  a 
aatelllte-derivad  layer  would  have,  at  a  minimum,  a  vlaual  or  Infrared  aource 
indicated  plua  an  eatlmatad  baae  indicated.  An  actual  layer  will  have  at 
leaat  one  aource  indicated. 

The  aource  flag*  are  alao  a  function  of  the  procaaaora,  aa  ehovn  in  Tabla 

8.5. 
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Table  8.5 

SOURCE  PARAMETER/PROCESSOR  RELATIONSHIP 


Processor 

Conventional 

Satellite 

Merge  (1) 

Bogus 

Source  Parameter 

Low  cloud  perslated 

eource 

Estimated  base 

source 

source 

modify 

eource 

Estimated  top 

source 

modify 

source 

RAOB  (best  report) 

source 

modify 

PIREP  (best  report) 

source 

modify 

Surface  oba  (beat  rpt) 

source 

modify 

Visual  satellite  data 

source 

modify 

Infrared  satellite  data 

source 

modify 

(1)  The  Merc*  Processor  nodiflea  the  eource  data  in  iti  aelection  or 
rejection  of  the  data  from  a  proceaaor. 

8.4  Diagnostic  Information 


To  aid  analyata  maintaining  the  RTNEPH  database,  a  aignif leant  amount  of 
dlagnoetic  information  la  provided  in  the  databaae.  Although  thla  data  la 
deaigned  for  quality  control  purposes,  any  uaer  of  the  databaae  might  need  to 
uee  thla  information,  which  mainly  conalata  of  flags  like  the  layer  source 
information.  Tho  diagnostic  Information  la: 

a.  Bogus  flag,  which  Indicates  whether  the  grid  point  haa  information 
derived  from  manually  input  data  via  the  Bogus  Proceaaor)  this  flag  la  always 
cleared  out  in  the  archived  databases, 

b.  Beat  Report  flag,  which  indicates  whether  a  beat  report  from  the 
Conventional  Proceaaor  was  Included  at  thla  point. 

c.  Spread  Data  flag.  Which  indicates  whether  conventional  data  from  a 
beat  raport  was  spread  to  thla  point  from  a  nearby  point  with  Beat  Report  Data. 

d.  Visual  Satellite  flag,  which  indicates  visual  satellite  data  was 
available  for  consideration  at  the  point. 

e.  Infrared  Satellite  flag,  which  Indicates  whether  Infrared  satellite 
data  was  available  for  consideration  at  the  point. 

f.  Low  cloud  persistence  flag,  which  indicates  whether  low  cloud  was 
persisted  from  the  previous  analysis. 

g.  Visual  satellite  data  only  flag,  which  identifies  that  visual 
satellite  data  was  the  only  data  source  available. 

h.  Second  weather  flag,  which  indicates  that  fog  or  haze  was  present  in 
addition  to  the  weather  indicated  in  the  primary  weather  information. 
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1.  Tine  of  oldest  data  at  the  grid  point.  This  information  coupled  vith 
the  previously  provided  valid  time  of  the  data,  provides  a  vindov  indicating 
when  all  the  data  at  the  point  was  valid.  This  vindov  is  inportant  for  the 
definition  of  a  valid  time  when  the  satellite  and  conventional  data  are,  as  in 
the  usual  case,  of  different,  though  close,  valid  times. 

j.  Best  Report  RAOB  flag,  which  indicates  that  the  grid  point  had  a  heat 
report  and  that  the  best  report  had  RAOB  data. 

k.  Best  Report  P1REP  flag,  same  as  j,  but  for  PIRBP  data. 

i 

l.  Beat  Report  surface  observation  flag,  same  aa  J,  but  for  a  surface 
observation, 

m.  Ice  flag,  which  indicates  the  point  was  a  water  point  with  ice. 

n.  Snow  flag,  which  indicates  the  ground  was  snow-covered  at  the  point. 

o.  Tropica  flag,  which  indicates  that  grid  point  is  within  the  RTNKPH'a 
tropical  region. 

p.  Infrared  daylight  flag,  which  indicates  the  infrared  data  considered 
were  daytime  data. 

q.  Infrared  eun-side  flag,  which  indicates  the  Infrared  data  at  the  point 
were  on  the  sunward  side  of  the  quarter  orbit  of  date. 

r.  Visual  daylight  flag,  same  aa  p,  but  for  visual  data. 

s.  Visual  sun-aide  flag,  same  as  q,  but  for  visual  data. 

t.  Sunglint  flag,  indicates  the  visual  data  fell  in  the  sunglint  cone. 

u.  Infrared  satellite  identifier,  indicates  which  of  the  up  to  four 
meteorological  satellites  was  the  source  of  this  point's  infrared  data.  This 
is  a  coded  value  end,  to  be  used,  requires  knowledge  of  RTNEPH  chronology. 

v.  Visual  satellite  identifier,  same  as  u,  but  for  the  source  of  visual 
satellite  data. 

Some  of  the  above  may  seem  redundant  to  earlier  values,  such  as  in  the  layer 
source  Information,  but  actually  provide  additional  information.  Por  example, 
the  layer  flag  for  visual  data  would  Indicate  that  a  specific  layer  was 
actually  based  on  visual  data.  The  diagnostic  entry  for  visual  data,  however, 
would  indicate  that  visual  data  were  considered  in  the  analysis  even  though 
they  were  not  an  actual  factor. 

Just  as  vith  the  earlier  sets  of  information,  one  should  consider  the  effects 
of  the  individual  processors  on  the  diagnostic  entries.  This  is  shown  in 
Table  8.6. 
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Table  8.6 

DIAGNOSTIC  PARAMETER/PROCESSOR  RELATIONSHIP 


Processor  Conventional  Satellite  Merge  Bogus 


Parameter 


Bogus  flag 

modify  (1)  source 

Bast  Report  flag 

source 

Spread  flag 

source 

Visual  data  flag 

source 

modify  (1) 

IR  data  flag 

source 

modify  (1) 

Low  cloud  persisted 

source 

Visual  data  only  flag 

source 

Second  Weather  flag 

source 

modify  (1) 

Oldest  data  (2) 

source 

source 

modify 

Best  Report  -  RAOB 

source 

modify  (1) 

Best  Report  -  PIREP 

source 

modify  (1) 

Best  Rsport  -  SURFACE 

source 

modify  (1) 

Ice  flsg 

source  (3) 

Snow  flag 

source  (3) 

Tropics  flag 

source 

IR  daylight 

source  (3) 

IR  aun-alda 

source  (3) 

Visual  daylight 

source  (3) 

Visual  sun-side 

source  (3) 

Sunglint 

source  (3) 

IR  satellite  ID 

source  (3) 

Visual  satellite  ID 

source  (3) 

(1)  The  Merge  Processor  can  modify  a  flag  based  on  the  Merge's  decision 
to  include  or  exclude  the  specific  data. 

(2)  The  Merge  Processor  calculstes  (modifies)  the  oldest  data  information 
based  on  Inputs  from  the  Conventional  ana  Satellite  processors  (i.e.,  both  can 
ba  sources  for  the  input  information). 

(3)  A(  ual  sources  are  other  databases.  For  example,  the  Satellite 
Processor  gets  the  Ice  flag  from  the  terrain  and  geography  database. 


SECTION  9.  QUALITY  CONTROL 

Quality  control  (QC)  is  difficult  due  to  the  large  amount  of  data  processed 
and  the  real  time  nature  of  the  RTNEPH .  Despite  the  difficulties,  RTNSFH 
undergoes  many  different  forms  of  QC  to  provide  a  comprehensive  QC  effort. 
These  range  from  visual  Inspection  of  the  analysis  and  noting  deficiencies  to 
changing  the  analysis  via  the  Bogus  Processor.  We'll  discuss  each  method  in 
detail  beginning  with  known  ETNEPH  problem  areas. 

9.1  Known  RTNEPH  Analysis  Deficiencies 

RTNEPH  has  several  analysis  deficiencies.  These  include: 

a.  Under interpreting  low  clouds.  This  occurs  when  infrared  satellite 
data  is  the  only  available  source,  the  cloud  temperatures  are  near  the  surface 
temperature  and  are  therefore  interpreted  to  be  the  surface.  This  problem  can 
be  "corrected''  by  tuning  adjustments,  but  may  lead  to  over  interpretation  in 
clear  areas. 

b.  Coastline  interpretation.  Over  or  under  interpretation  may  occur  due 
to  choosing  a  representative  background  field  (brightness  or  temperature)  to 
represent  the  gridpoint  area.  For  instance,  the  sea-surface  temperature  is 
nearly  always  different  from  the  land  temperature.  Therefore,  when  the 
Satellite  Processor  builds  the  histogram,  it  could  be  using  a  surface 
temperature  more  representative  of  the  land  and  therefore  may  analyse  clouds 
over  water  when  there  aren't  any. 

c.  Snow  and  ice.  RTNEPH  is  kept  abreast  of  vhere  snow  and  ice  are 
located  by  the  SNODEF  model  (Hall,  1986).  If  this  Information  is  Incorrect, 
then  the  visual  data  may  add  a  stratus  cloud  layer.  Additionally,  the  snow 
temperature  may  be  cooler  than  what  the  surface  temperature  model  generates 
and  therefore,  over  interpretation  will  result. 

d.  High  plateaus.  Areas  such  as  the  Tibetan  plateau  are  routinely  over 
interpreted  due  to  the  cold  surface  temperature. 

e.  Small-scale  clouds.  Small-scale  clouds  such  as  fair  weather  cumulus 
are  difficult  to  detect  due  to  their  small  footprint.  They  are  routinely 
under interpreted. 

In  addition  to  the  analysis  deficiencies  mentioned  above,  cloud  typing,  thin 
cloud  detection,  and  cloud  thickness  remains  suspect.  However,  AFGWC 
presently  doesn't  have  the  means  to  QC  these  items. 

9.2  Objective  Analysis 

The  Satellite  and  Merge  Processors  do  some  error  checks  to  prevent  a  poor 
analysis.  In  general,  if  a  critical  data  file  (RTNEPH  analysis,  geography, 
etc.)  isn't  available,  then  the  program  will  abort.  If  the  file  isn't 
critical,  then  the  processors  will  use  default  values. 
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9.2.1  Satellite  Processor  Quality  Control 

The  Satellite  Processor  will  verify  if  the  correct  data  are  processed  by 
making  sure  the  identifying  information  matches  what  is  in  the  SGDB.  Its 
other  check  is  to  verify  the  satellite  data  are  within  the  look  and  zenith 
angle  limit  criteria  for  analysis. 

9.2.2  Merge  Processor  Quality  Control 

The  Merge  Processor  checks  for  cloud  consistency  for  all  analyses 
(conventional,  satellite,  and  final)  as  outlined  in  section  6.3.1.  If  an 
error  occurs,  the  Merge  Processor  "fixes"  the  inconsistency  and  prints 
diagnostic  output. 

9.3  Subjective  Methods 

Subjective  methods  provide  the  greatest  amount  of  QC.  These  include  bogus 
processor  corrections,  tuning,  and  written  records  of  RTNEPH  quality. 

9.3.1  Bogus  Processor  Corrections 

The  Bogus  Processor,  described  in  Section  7,  provides  the  most  effective  QC. 
Not  only  are  problem  areas  Identified,  but  they  are  fixed  on  the  spot. 

9.3.2  Tuning 

The  process  of  tuning  the  RTNEPH  is  to  adjust  parameter(s)  in  the  tuning 
database  to  make  a  better  analysis.  The  most  common  tune  is  to  adjust  the 
surface-minus- infrared  skin  temperature  thresholds.  Lowering  these  thresholds 
adds  more  clouds;  raising  the  thresholds  reduces  clouds.  This  tune  is 
normally  done  on  a  weekly  basis.  Other  tunes  such  as  adjusting  the  spreading 
radii  criteria  are  done  on  an  infrequent  basis. 

9.3.3  Quality  Control  Logs 

RTNEPH  QC  at  AFGWC  is  documented  in  two  places.  The  first  is  the  QC  log  for 
OL-A,  USAFETAC.  They  use  it  to  help  their  QC  of  the  climatological  RTNEPH 
database  (Zamiska,  1986).  AFGWC  provides  information  for  this  QC  log  by 
overlaying  the  RTNEPH  analysis  against  the  SGDB.  Satellite  analysts  annotate 
which  RTNEPH  boxes  have  problems.  The  second  log  is  a  subjective,  random 
on-the-spot  check  done  by  the  RTNEPH  OIC.  This  log  is  attached  to  the  cloud 
models  section  end-of-month  QC  reports. 


SECTION  10.  APPLICATIONS 


10.1  Data  Display  Programs 

The  Display  Processor  for  RTNEPH  is  NEFDIS.  NEFDIS  can  display  any  of  the 
RTNEPH  data  fields  in  any  of  four  formats.  The  display  formats  are:  A 
hox-by-box  display  (one  box  per  page)  and  polar  stereographic  hemispheric 
displays  with  scales  of  1:7.5  million,  1:15  million,  and  1:30  million.  NEFDIS 
can  display  nearly  all  of  the  parameters  from  both  the  real-time  and  synoptic 
RTNEPH  databases,  as  well  as  data  from  the  satellite,  best  reports,  geography, 
temperature,  and  background  brightness  support  databases. 

A  second  RTNEPH  display  program  is  CLDDIS.  This  program  displays  cloud  fields 
for  the  AFGWC  forecast  floor  (WFP).  It  displays  tops,  types,  bases,  and 
amounts  for  clouds  at  or  above  10,000  feet  with  at  least  A/8  coverage.  It  is 
useful  for  making  horizontal  weather  depictions. 

A  third  RTNEPH  display  program  displays  RTNEPH  total  cloud  amounts  in  eighths 
in  "DMSP"  space.  It  is  useful  for  determining  bogus  areas  for  the  bogus 
processor.  An  example  is  shown  in  Figure  10.1.  In  Figure  10.1  notice  the 
apparently  incorrectly  analyzed  cloud  amounts:  areas  of  one-eighth  coverage 
in  north  central  Florida,  in  the  Gulf  of  Mexico  south  of  New  Orleans,  and 
south  central  Mississippi;  and  a  few  grid  points  analyzed  as  clear  near  Cuba 
that  appear  mostly  cloudy  or  overcast  and  analyzed  as  clear;  and  an  area  of 
one  and  four-eighths  northwest  of  Tampa  Bay  in  the  Gulf  of  Mexico.  The 
analyst  could  bogus  in  his  subjectively-determined  cloud  amounts  in  these 
areas. 

10.2  Cloud  Forecast  Models 

The  RTNEPH  database  is  primarily  used  to  initialize  the  cloud  forecast  models 
5LAYER,  HRCP,  and  TR0NEW. 

10.2.1  5 LAYER 

The  5 LAYER  model  (Crum,  1987),  is  the  main  cloud  forecast  model  at  AFGWC. 

5 LAYER  produces  cloud  forecasts  at  the  gradient,  850,  700,  500  and  300  mb 
levels.  The  forecasts  are  produced  every  three  hours  in  the  northern 
hemisphere  and  every  six  hours  in  the  southern  hemisphere.  Forecasts  are  made 
for  every  three  hour  period  out  to  A8  hours  (northern)  or  24  hours 
(southern).  5LAYER  compresses  the  eighth-mesh  RTNEPH  data  into  a  half-mesh, 
100  nm  resolution  analysis.  The  analyses  are  made  over  a  subset  of  each 
hemisphere  known  as  the  "octagon".  5LAYER ' s  primary  data  sources  are  RTNEPH 
clouds  and  Global  Spectral  Model  winds  and  temperatures.  SLAYER  uses  the 
analyses  to  forecast  layered  cloud  amounts,  total  cloud,  dew-point 
depressions,  temperatures,  present  weather,  and  other  fields. 

10.2.2  HRCP 

The  High  Resolution  Cloud  Prognosis  model  (HRCP)  produces  short  range 
forecasts  over  selected  areaB  of  each  hemisphere.  HRCP  uses  5LAYER  and  RTNEPH 
data  to  make  3,  6,  and  9  hour  forecasts  of  total  cloud,  layered  cloud,  total 
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probability  clear,  and  other  parameter*.  The  forecasts  are  eighth  mesh,  and 
are  made  using  selected  RTNEPH  boxes  (up  to  13  boxes  on  any  one  run). 

10.2.3  TRONEW 

The  TRONEW  model  produces  half-mesh  total  cloud  forecasts  over  the  tropics 
(the  areas  not  covered  by  SLAYER).  The  forecasts  sre  made  for  each  three  hour 
period  out  to  21  hours.  The  model  uses  diurnal  persistence  to  make  the 
forecast;  the  current  analysed  cloud  is  the  24  hour  forecast  cloud.  TRONEW 
takes  RTNEPH  total  cloud  data  converted  to  total  probability  clear  and 
compacts  it  to  half  mesh. 

10.3  Other  Models 

AFGWC  has  models  (AGROMET  and  PRANL)  for  precipitation  estimation  which  use 
the  RTNEPH  data.  The  cloud  types  and  amounts  provide  useful  information  for 
estimating  precipitation  in  these  models. 

10.4  Archived  Data 

The  RTNEPH  synoptic  database  is  saved  on  tape  every  three  hours  and  sent  to 
the  USAF  Environmental  Technical  Application  Center,  Operating  Location  A 
(OL-A,  USAFETAC)  at  Asheville,  NC.  Potential  users  should  contact  OL-A, 
USAFETAG  for  Information  on  obtaining  tha  data. 
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SECTION  11.  FUTURE  PUNS 


In  response  to  an  AFGWC  computer  upgrade,  new  data  sources,  and  better 
algorithm  techniques,  the  RTNEPH  will  undergo  a  technical  enhancement.  This 
enhancement  will  seek  to  reduce  deficiencies  in  the  RTNEPH  described  in 
section  9.1,  producing  a  more  accurate  model. 

11.1  Surface  Temperature  Model  Rewrite 

Perhaps  the  most  significant  enhancement  to  the  RTNEPH  will  be  the  surface 
temperature  model  rewrite  (see  Appendices  C  and  D  of  Fye,  1978).  Recall  that 
accurate  surface  temperatures  are  important  to  low  cloud  determination. 
Therefore,  a  more  accurate  surface  analysis  and  forecast  will  help  the 
RTNEPH.  The  tentative  date  for  this  rewrite  completion  is  1990. 

11.2  Incorporation  of  SSMI/I  Data 

Special  Sensor  Microwave  Imager  (SSM/I),  a  passive  microwave  imager,  will  fly 
on  new  DMSP  satellites.  SSM/I  information  can  be  very  helpful  in  determining 
whether  clouds  are  present  and  the  amount  over  snow  and  land  arsaa,  and 
provide  inputs  to  surface  temperature  and  snow/ice  boundary  models.  Hughes 
Aircraft  Corporation  has  been  contracted  to  provide  a  multi-spectral  module  to 
process  Infrared  and  SSM/I  data  to  be  delivered  in  1988. 

11.3  1.5  nm  SGDB  (POSIDB) 

The  AFGWC  SGDB  will  increase  its  horizontal  resolution  from  3  nm  to  1.5  nm. 
This  new  database  will  be  called  Polar  Orbiting  Satellite  Imagery  Database 
(POSIDB).  In  addition  to  the  Increased  horizontal  resolution,  POSIDB  will 
Increase  both  the  infrared  and  visual  grayahade  resolution  from  63  to  255 
grayshades.  Also,  it  will  allow  multiple  channels  to  be  stored  vice  only  the 
present  infrared  and  visual  channels.  These  changes  will  help  RTNEPH  detect 
clouds  with  a  smaller  footprint  than  present  and  may  also  allow  use  of 
multi-spectral  techniques. 

11.4  Multi-Spectral  Techniques 

POSIDB  may  allow  the  addition  of  extra  channels  of  data  to  be  stored  in  the 
SGDB.  Multi-spectral  techniques  using  NOAA  AVHRR  data  have  been  shown  to  be 
able  to  pick  up  low  clouds  and  fog  at  night  (Turner  et.  al.,  1986).  ThiB  is  a 
present  weakness  of  the  RTNEPH  due  to  its  use  of  an  IR  thresholding 
technique.  Other  multi-spectral  techniques  may  improve  other  RTNEPH  analysis 
problems. 

11.5  New  Clustering  Algorithm 

AFGL  is  preparing  their  clustering  algorithm  (d'Entremont  et.  al.,  1982)  for 
use  in  the  RTNEPH.  Their  algorithm  appears  to  be  more  accurate  in  determining 
cloud  layers  and  total  cloud.  It  will  be  Implemented  after  POSIDB  is 
implemented  because  the  algorithm  requires  a  16  X  16  array  of  grayshades.  For 
an  l/8th  mesh  analysis,  POSIDB  will  provide  the  correct  resolution  of 
grayshades. 
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11.6  l/16th  Mesh  RTHEPH 

POSIDB,  with  Its  finer  resolution,  will  allow  RXNEPH  to  expand  its  horizontal 
resolution  to  l/16th  mesh  <12.5  nm)  in  the  mid  1990s.  This  will  help  RTHEPH 
to  analyze  smaller  scale  clouds  better.  It  also  may  reduce  the  coastline 
Interpretation  problem. 

11.7  Satellite  Data  Handling  System  Impacte 

APOWC's  naw  Satellite  Data  Handling  System  (8DHS)  will  change  how  the  Bogus 
Processor  works.  It  will  also  open  up  application  and  QC  options. 

8DHS  will  allow  the  RTHEPH  data  to  be  over lay ed  on  the  displayed  satellite 
imagery.  After  the  cloud  analyst  encircles  the  bogused  area,  SDKS  will  fill 
in  the  bogused  area.  This  will  replace  the  fill-in  part  of  the  Bogus 
Processor.  It  won't  however,  replace  the  other  parts  of  the  Bogus  Processor. 
SDHS  will  allow  easier  use  of  RTHEPH  in  horisontal  weather  depictions.  Also, 
it  will  reduce  the  effort  necessary  for  RTHEPH  QC. 
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SECTION  12.  CONCLUSION 

We 'via  discussed  the  AF6WC  cloud  analysis  model,  the  RTNEPH .  It  continues  to 
be  a  unique  nephanalysis  program  providing  timely,  accurate  cloud  analysis  at 
25  nm  horizontal  resolution  for  the  entire  globe.  RTNEPH  will  continue  to 
change  as  new  data  techniques  become  available.  Thus  RTNEPH  will  continue  to 
improve  its  analysis  for  users  and  applications  programs. 
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Atmospheric  Sciences  Laboratory,  Whitt  Sands  Hisalle  Kange,  KM  $8002-5501 

Ttchnlcal  Library,  Dugvay  Proving  Ground  Dugvay,  UT  84033-5501 . 

AWSTL,  Scott  AFB,  IL  62225-5438 . 

MOAA  (W/FC),  Federal  Coordlnatore  Office,  Kockvllle,  MD  20852 . . . 

National  Meteorological  Center,  N0AA/W1NMC,  Washington  DC  20033..... . 


